Développement d’un nouveau compilateur JIT pour PostgreSQL

• Après l’introduction dans Python 3.13 d’une nouvelle méthodologie de construction de compilateur JIT (copy-patch), il a été décidé d’essayer de l’appliquer à PostgreSQL.
• Présentation d’une nouvelle approche appelée pg-copyjit, qui vise à améliorer la vitesse du serveur PostgreSQL.
• Tout le code est expérimental et doit être examiné par des experts avant toute utilisation dans un environnement de production.

Au début, il n’y avait pas de JIT, puis le compilateur JIT LLVM est apparu

• La compilation JIT basée sur LLVM a été introduite dans PostgreSQL, mais LLVM présente certains aspects peu adaptés au JIT.
• Les optimisations LLVM sont coûteuses, et sans elles la compilation elle-même peut perdre tout son intérêt.
• Comme l’estimation du coût des requêtes dans PostgreSQL n’a pas de lien direct avec le temps d’exécution réel, de nombreux utilisateurs désactivent le compilateur JIT.

En 2021, le copy-and-patch a été décrit

• Il est nécessaire de générer aussi vite que possible un code rapide et de qualité suffisante.
• L’approche copy-patch génère rapidement du code à l’aide de stencils (fonctions modèles) écrits en C.
• Il suffit de copier le stencil dans une nouvelle zone mémoire, de combler les trous, puis de sauter directement vers la fonction « compilée ».

Introduire copy-and-patch dans PostgreSQL

• Construire un nouveau moteur JIT pour PostgreSQL n’est pas très difficile, et il est proposé de transformer LLVM en plugin afin de permettre l’introduction d’autres compilateurs JIT.
• Il suffit de fournir une unique fonction _PG_jit_provider_init et d’initialiser trois callbacks : compile_expr, release_context, reset_after_error.
• L’algorithme copy-patch est simple : il recherche et ajoute le stencil correspondant à chaque opcode, puis remplit les trous avec les valeurs nécessaires.

État actuel

• Cela fonctionne avec PostgreSQL 16 et ne prend actuellement en charge que AMD64.
• La génération de code s’effectue en quelques centaines de microsecondes, ce qui la rend utilisable même pour des requêtes courtes.
• Ce n’est pas encore le stade de l’optimisation, mais on constate déjà de meilleures performances que l’interpréteur.
• Peu d’opcodes sont encore implémentés, mais pour les requêtes qui ne sont pas encore prises en charge, l’interpréteur PostgreSQL prend le relais.

À faire...

• Il s’agit d’une preuve de concept, et la possibilité de le construire ou de le packager facilement n’est pas encore un objectif.
• L’accent est mis sur l’implémentation d’un plus grand nombre d’opcodes et sur la recherche d’optimisations.
• Le portage vers d’autres architectures est également sérieusement envisagé.

Remerciements

• Des remerciements sont adressés à l’employeur actuel, Entr’ouvert, qui a permis aux collègues de consacrer du temps à ce projet.
• Des remerciements vont aussi aux amis DBA, avec une recommandation d’essayer PoWA.

L’avis de GN⁺

• Cet article présente une nouvelle approche visant à améliorer les performances du serveur de base de données PostgreSQL. Cela peut intéresser les administrateurs de bases de données et les développeurs.
• Avant d’appliquer un code expérimental dans un environnement de production réel, des tests et validations approfondis sont indispensables. Cela vise à prévenir des risques comme la perte de données ou les interruptions de service.
• Par rapport aux compilateurs JIT existants comme LLVM, l’approche copy-patch permet une génération de code plus rapide, ce qui peut aussi la rendre utile pour les requêtes courtes.
• Si cette technologie est largement adoptée par la communauté PostgreSQL, elle pourrait ouvrir un nouveau chapitre dans l’optimisation des performances des bases de données, avec une extension du support à diverses architectures.
• D’un point de vue critique, il s’agit encore d’un stade précoce, et des recherches et développements supplémentaires seront nécessaires pour voir comment les gains de performance se manifesteront en environnement de production réel.