On a tous vu des requêtes lentes en production, et c'est difficile de prédire lesquelles vont exploser en premier. Certaines requêtes, cependant, peuvent vous mettre la puce à l'oreille quand vous faites votre premier EXPLAIN et vous faire dire qu'elles n'auraient jamais dû arriver en production.

À travers des exemples réels, je vous montrerai comment réécrire une requête peut transformer un job de 3 heures en un job de 3 minutes (et oui, tout le monde ne pense pas de manière holistique), comment EXPLAIN ANALYZE vous dit exactement ce qui ne va pas (fini les suppositions !), et comment les index peuvent aider ou plomber vos performances (oui, cet index que vous avez ajouté parce que Stack Overflow l'a dit).

Il semble aujourd'hui primordial de s'intéresser aux performances en base de données– parce que quel est l'intérêt de passer des heures à optimiser le code applicatif si votre requête fait un scan séquentiel ? Vous obtiendrez peut-être le graal avoir des requêtes stables quelle que soit la quantité de données requêtée. Aujourd'hui, nous levons le voile sur l'optimiseur de Postgres et vous verrez que ce n'est pas de la sorcellerie!