**Pourquoi utiliser les IO directes et asynchrones ?** Jusqu'à maintenant, PostgreSQL se base sur l'OS pour l'ensemble de ses IO. PostgreSQL lui demande des blocs, que l'OS a déjà en cache, ou qu'il va chercher sur disque. Cependant un chantier est en cours pour passer, au moins partiellement, de ce mode d'accès aux données appelé _buffered IO_, à ce qu'on appelle des IO directes (ou _direct IO[^DIO]_). Dans beaucoup de cas, cela permet de déplacer les données directement du stockage vers le cache de PostgreSQL sans faire intervenir le CPU en utilisant la technologie DMA[^DMA]. Cela réduit la charge CPU et diminue la latence des IO. Un autre avantage de ce changement est une meilleure utilisation de la mémoire, puisque l'on évite une double mise en cache de certaines données (OS + PostgreSQL). Pour finir, cela permet de mieux contrôler les IO en tirant partie du fait que PostgreSQL a une meilleure connaissance du contexte dans lequel les IO sont réalisées. Cela donne, par exemple, plus de contrôle sur le timing où les écritures sont effectivement faites sur le stockage (`fsync`). Cependant, en donnant à PostgreSQL la main sur l'exécution des IO, on se passe des mécanismes en place au niveau du système d'exploitation comme la mise en cache des fichiers et le _kernel read ahead_. Seule, cette modification serait donc délétère pour les performances. On peut facilement s'en rendre compte en expérimentant l'option `debug_io_direct`, qui a été ajoutée en version 16 et qui permet de demander à l'OS d'utiliser le cache au minimum pour les relations et/ou les WAL. Comme son nom l'indique, cette option est destinée aux développeurs de PostgreSQL, et surtout pas à la production. Un préalable aux IO directes est donc de mettre en place toute une infrastructure pour réaliser des IO asynchrones (appelées AIO[^AIO] dans la suite de ce texte) afin de grouper et de réaliser les IO en avance de phase (_prefetch_) et de manière concurrente. Ces améliorations laissent espérer beaucoup d'améliorations de performances notamment dans le cadre des écritures et synchronisations des WAL. Le parcours séquentiel d'une table avec plusieurs segments est un autre cas où le contexte des IO est important. En effet, pour le _kernel read ahead_ un changement de fichiers provoque des fluctuations dans l'usage du _prefetch_ car le noyau ne sait pas qu'il s'agit de la même table et que l'on va continuer à lire le segment et les suivants jusqu'au bout. PostgreSQL, lui, est au courant de ce contexte et pourra continuer le prefetch avec la même agressivité. Pour finir, les IO directes et asynchrones nécessitent des quantités de _shared buffers_ importantes pour fonctionner de manière optimale. Mettre en place ce nouveau mode de fonctionnement touche donc énormément d'aspects du fonctionnement de PostgreSQL et il faudra plusieurs versions pour en tirer tous les bénéfices. Certaines fonctionnalités exploitaient déja les io asynchrones du système d'exploitation comme la [recovery en version 15] (`recovery_prefetch`) et les extensions de relations en masse en version 16. Plus ancien, le _bitmap heap scan_ a longtemps été le seul cas où le _prefetch_ était utilisé. D'autres améliorations ont été faites en version 17, avec la création d'une nouvelle API permettant de [regrouper plusieurs IO] en un seul appel système. Actuellement seules l’implémentation du parcours séquentiel (_Seq Scan_), celle de `ANALYZE`, et celle de l'extension `pg_prewarm` utilisent cette nouvelle API. Cette nouvelle version continue donc l'effort engagé sur l'amélioration du système d'IO de PostgreSQL en ajoutant un système pour gérer les IO asynchrones qui s'intègrent avec les fonctionnalités existantes. Le travail pour utiliser les IO directes ne viendra « que » plus tard. [recovery en version 15]: https://dali.bo/workshop15_html#permettre-le-pre-fetch-du-contenu-des-fichiers-wal-pendant-le-recovery [regrouper plusieurs IO]: https://dali.bo/workshop17_html#regroupement-des-io [^DMA]: _Direct Memory Access_ [^AIO]: _Async IO_ [^DIO]: _Direct IO_