Postgres 19 et les « conseils de plan » : quand l'expertise humaine reprend la main sur l'optimiseur
Il y a des annonces qui font l'effet d'un séisme dans une communauté. L'inclusion des query hints — ou plutôt des conseils de plan — dans le feature freeze de PostgreSQL 19 en fait partie. Une fonctionnalité que beaucoup juraient ne jamais voir le jour débarque finalement, sous une forme soigneusement pensée. Chez MulerTech, nous développons des applications PHP/Symfony qui s'appuient massivement sur PostgreSQL, et cette évolution nous touche directement. Voici pourquoi elle mérite toute votre attention.
Un débat vieux comme PostgreSQL
Pour comprendre l'ampleur de l'événement, il faut revenir sur la position historique de la communauté PostgreSQL. Pendant des années, le wiki officiel était sans ambiguïté : « Nous ne souhaitons pas implémenter les hints de la manière dont ils existent dans d'autres bases de données. » Et les raisons avancées étaient solides :
- Les hints créent des cauchemars de maintenance : ils se lient à un plan d'exécution figé qui devient obsolète dès que les données évoluent.
- Ils cassent lors des mises à jour de version.
- Ils découragent l'analyse des causes profondes : au lieu de corriger les statistiques ou les index, on plaque un pansement.
- Ils freinent l'amélioration du planificateur lui-même, car les utilisateurs cessent de remonter les bugs.
Ces arguments restent valides aujourd'hui. L'optimiseur de PostgreSQL est, dans l'immense majorité des cas, plus intelligent qu'une instruction manuelle. Mais « l'immense majorité des cas » n'est pas « tous les cas ».
Ce que Postgres 19 introduit vraiment
La communauté PostgreSQL n'a pas capitulé sur le fond : elle a trouvé une voie élégante. PostgreSQL 19 n'introduit pas des hints au sens Oracle ou MySQL du terme. Il introduit deux nouveaux modules contrib :
pg_plan_advice : permet d'injecter des conseils sur le plan d'exécution d'une requête (choix de jointure, utilisation d'index, etc.).pg_stash_advice : permet de stocker et de rejouer ces conseils de manière persistante.
Le choix du mot « advice » (conseil) plutôt que « hint » (indice/forçage) est délibéré. Ces modules ne forcent pas le planificateur — ils lui suggèrent. La nuance est importante : PostgreSQL conserve le droit de déroger si le conseil mène à un plan manifestement sous-optimal. C'est une collaboration entre l'humain et la machine, pas un court-circuit.
Le vrai enjeu pour les applications critiques
Dans nos projets PHP/Symfony chez MulerTech, nous rencontrons régulièrement un scénario précis : une requête complexe, souvent générée par Doctrine ORM, se comporte parfaitement en développement et sur les premières semaines de production — puis, après quelques millions de lignes supplémentaires, l'optimiseur bascule sur un plan d'exécution catastrophique. Les statistiques automatiques n'ont pas encore rattrapé la réalité du volume de données.
Jusqu'à présent, les options étaient limitées :
- Réécrire la requête pour guider implicitement le planificateur — fragile et illisible.
- Forcer un
ANALYZE fréquent — coûteux en I/O sur de grandes tables.
- Utiliser des extensions tierces comme
pg_hint_plan — efficace, mais non officiel et risqué lors des montées de version.
Avec pg_plan_advice, une quatrième voie apparaît : documenter et appliquer un conseil de plan validé par l'équipe technique, de manière officielle, versionnée et maintenable. C'est exactement le chaînon manquant entre l'automatisme pur du planificateur et l'intervention chirurgicale de l'expert.
Ce que cela change dans notre pratique
L'arrivée de ces modules ne signifie pas qu'il faut se précipiter à coller des conseils partout. La philosophie PostgreSQL tient toujours : commencez toujours par corriger les statistiques, les index et le schéma. Les conseils de plan sont un outil de dernier recours, pas un substitut à une bonne conception.
En revanche, pour les applications critiques — e-commerce à fort trafic, ERP métier, plateformes SaaS multi-tenants — ils offrent quelque chose d'inestimable : la stabilité prédictible. Pouvoir garantir qu'une requête stratégique empruntera toujours le même plan d'exécution, indépendamment des fluctuations statistiques, c'est une promesse de SLA que beaucoup de nos clients attendent.
Concrètement, nous anticipons plusieurs cas d'usage dans nos stacks Symfony :
- Stabilisation des requêtes de reporting générées dynamiquement, où le plan peut varier selon les paramètres.
- Protection des requêtes critiques de transaction lors des pics de charge, quand les statistiques sont temporairement désynchronisées.
- Documentation des décisions d'optimisation : un conseil de plan explicite dans le code est bien plus lisible qu'une réécriture cryptique de requête.
Conclusion : l'automatisme augmenté
L'intégration des conseils de plan dans PostgreSQL 19 illustre une maturité : celle d'un système qui reconnaît que l'expertise humaine et l'intelligence automatique ne s'opposent pas, elles se complètent. PostgreSQL ne renonce pas à son planificateur — il lui offre un interlocuteur.
Chez MulerTech, nous suivrons de près la stabilisation de ces modules contrib d'ici la sortie officielle de PostgreSQL 19. Et si vous gérez des applications PHP/Symfony avec des enjeux de performance sur PostgreSQL, c'est le bon moment pour auditer vos requêtes critiques et identifier celles qui bénéficieraient d'un tel mécanisme.
📖 Source originale : cet article s'appuie sur l'analyse de Shaun Thomas publiée sur pgEdge — une lecture recommandée pour aller plus loin dans les détails d'implémentation.
