Une requête est devenue lente après une mise en production. Expliquez-moi comment vous lisez le plan d'exécution et décidez quoi changer.

Lancez explain analyze pour obtenir le vrai plan avec les nombres de lignes et les temps réels, puis regardez le noeud qui consomme le plus de temps et comparez les lignes estimées aux lignes réelles. Un gros écart signifie de mauvaises statistiques, donc le planificateur a choisi la mauvaise jointure ou le mauvais parcours. Cherchez les parcours séquentiels sur les grosses tables, les boucles imbriquées déclenchées par une sous-estimation, et les tris qui débordent sur disque. Corrigez avec un index, des statistiques à jour, ou un prédicat réécrit que l'index peut utiliser.

Je commence par explain analyze avec buffers pour avoir de vrais temps et de vrais comptages, idéalement sur un volume comparable à la production parce qu'un plan sur un petit jeu de données ne m'apprend rien. Ensuite je trouve le noeud qui consomme le plus de temps et je compare son estimation au réel. S'il estimait une ligne et en a obtenu cinquante mille, le planificateur a choisi une boucle imbriquée qui est maintenant une catastrophe, et la cause profonde est en général des statistiques périmées ou un prédicat corrélé que le planificateur ne sait pas modéliser. Ensuite je cherche les suspects habituels : un parcours séquentiel sur une grosse table, un filtre qui pourrait être une condition d'index, un tri qui déborde sur disque, ou une fonction enveloppant la colonne qui rend l'index inutilisable. C'est ce dernier cas que j'ai eu le plus récemment, un appel à lower sur une colonne e-mail qui ignorait l'index ; un index fonctionnel sur lower de l'e-mail l'a fait passer d'environ 900 millisecondes à deux. Ensuite je rejoue le plan pour confirmer que sa forme a changé, puisqu'une exécution plus rapide sur un cache chaud ne prouve rien.