PostgreSQL 19 : pg_plan_advice, le nouvel outil pour stabiliser vos plans d'exécution

Le 12 mars 2026, Robert Haas a intégré dans PostgreSQL 19 un nouveau module contrib baptisé pg_plan_advice. Cette fonctionnalité répond à un besoin concret rencontré par de nombreuses équipes de développement : comment s'assurer qu'une requête SQL continue à s'exécuter de manière performante dans le temps, même lorsque les statistiques évoluent ou que le volume de données change ?

Dans cet article, nous vous expliquons ce que ce module apporte, comment il fonctionne, et pourquoi les PME qui développent des applications web sur PostgreSQL ont tout intérêt à s'y intéresser.

Pourquoi le planificateur PostgreSQL peut devenir imprévisible

PostgreSQL dispose d'un planificateur de requêtes (query planner) sophistiqué. Son rôle est de déterminer automatiquement la meilleure façon d'exécuter une requête : quel index utiliser, dans quel ordre joindre les tables, quelle méthode de jointure appliquer (hash join, nested loop, merge join, etc.).

Dans la grande majorité des cas, le planificateur fait du bon travail. Mais il repose sur des statistiques collectées par ANALYZE. Si ces statistiques sont obsolètes, si la distribution des données est inhabituelle, ou si le volume de données augmente significativement, le planificateur peut soudainement choisir un plan moins efficace — voire catastrophique en termes de performances.

Pour contourner ce problème, les développeurs avaient jusqu'ici recours à des solutions souvent lourdes :

• Forcer des paramètres comme enable_seqscan = off au niveau de la session
• Utiliser des hints via des extensions tierces comme pg_hint_plan
• Réécrire les requêtes pour orienter le planificateur

Ces approches fonctionnent, mais elles manquent de lisibilité, sont difficiles à maintenir, et peuvent créer de nouveaux problèmes si la structure des données évolue.

Ce que pg_plan_advice apporte concrètement

pg_plan_advice propose une approche différente et plus structurée. Le module fonctionne en deux temps :

1. Analyser un plan existant pour produire des "conseils"

Après avoir exécuté une requête et obtenu un plan satisfaisant, vous pouvez demander à pg_plan_advice d'analyser ce plan et de produire une sortie textuelle — les fameux plan advice (conseils de plan). Ces conseils décrivent les décisions clés prises par le planificateur : quel index a été utilisé, quelle méthode de jointure a été choisie, etc.

2. Réinjecter ces conseils pour forcer les mêmes choix à l'avenir

Lors des prochaines exécutions de la requête, vous pouvez fournir ces conseils au planificateur. Celui-ci sera alors contraint de respecter les décisions décrites, reproduisant ainsi le plan d'exécution souhaité.

L'un des aspects les plus intéressants est la flexibilité : les conseils sont du texte lisible, que vous pouvez modifier manuellement ou même rédiger from scratch dans les cas simples. Il est également possible de ne fournir que des conseils partiels, pour contraindre certains choix tout en laissant le planificateur libre sur d'autres aspects.

⚠️ Attention : comme le souligne la documentation officielle, forcer le planificateur à des choix contraires à ses propres estimations peut produire des résultats désastreux. Cette fonctionnalité doit être utilisée par des personnes qui comprennent réellement le comportement de leurs requêtes et de leurs données.

Cas d'usage pratiques pour les applications web

Pour une PME qui exploite une application web PHP/Symfony connectée à PostgreSQL, pg_plan_advice ouvre plusieurs scénarios concrets :

Stabiliser les performances en production Vous avez identifié le plan optimal pour une requête critique (listing de produits, recherche, tableau de bord). Vous capturez les conseils correspondants et les associez à cette requête. Même si les statistiques évoluent suite à un pic de données, le plan reste stable.

Accélérer le diagnostic de régressions de performance Lorsqu'une requête ralentit soudainement, comparer les conseils du « bon » plan avec le plan actuel permet d'identifier rapidement quel choix du planificateur a changé.

Tester des plans alternatifs sans modifier la requête En éditant manuellement les conseils, un DBA expérimenté peut forcer PostgreSQL à tester des variantes de plans sans toucher au code SQL ni à la configuration globale du serveur.

Contrôle ciblé dans un environnement multi-tenant Dans une architecture où plusieurs clients partagent la même base, certains profils de données peuvent provoquer des plans sous-optimaux pour une minorité d'utilisateurs. pg_plan_advice permet d'intervenir de manière chirurgicale.

Ce que pg_plan_advice ne couvre pas (encore)

Il est important de noter que le module, dans sa version initiale, ne couvre pas l'intégralité des décisions du planificateur. Certains aspects restent hors de portée des conseils :

• Les décisions relatives à l'agrégation (choix de la méthode d'agrégat)
• Le choix de l'ordre de tri
• Certaines optimisations internes avancées

Ces limitations sont documentées et devraient évoluer dans les versions futures de PostgreSQL. Le module est conçu de manière extensible, ce qui laisse présager des améliorations progressives.

Conclusion : un outil de précision pour les équipes sérieuses

pg_plan_advice n'est pas un outil magique qui résout tous les problèmes de performance. C'est un instrument de précision, destiné aux équipes qui maîtrisent leur base de données et qui souhaitent un contrôle fin sur le comportement du planificateur.

Pour les développeurs PHP/Symfony qui travaillent sur des applications à fort trafic, cette fonctionnalité peut faire la différence entre des temps de réponse stables et des incidents de performance en production. Elle s'inscrit dans une démarche proactive d'optimisation, complémentaire aux bons réflexes habituels : indexation soignée, requêtes bien écrites, statistiques à jour.

PostgreSQL 19 n'est pas encore sorti en version stable au moment où nous écrivons ces lignes, mais ce module est d'ores et déjà disponible dans les versions de développement. C'est le bon moment pour commencer à l'explorer dans un environnement de test.

Source originale : Hubert 'depesz' Lubaczewski — Waiting for PostgreSQL 19 – Add pg_plan_advice contrib module