Analyseur EXPLAIN PostgreSQL

Collez le plan JSON issu de EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON) pour voir son arbre et les points chauds que cette page repère localement. Le plan est analysé dans votre navigateur ; la requête n’est pas exécutée et aucune base n’est contactée.

Fonctionne localement dans votre navigateur
Toutes les données de cet outil sont traitées dans votre navigateur.
JSON EXPLAINCollez le résultat JSON ; la base de données n'est jamais contactée.

Comment lire un plan d’exécution PostgreSQL depuis le JSON EXPLAIN

Collez la sortie JSON de EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON) et lancez Analyser le plan. La page dessine l’arbre du plan, totalise nœuds, coût, temps réel et lignes, puis liste les points chauds qu’elle sait repérer localement.

Le plan est analysé dans le navigateur ; aucune instruction n’est exécutée et rien n’est envoyé à une base ni à ce site. Seul le format JSON est lu — le format texte de psql ne le remplace pas.

  1. Exécutez la requête avec EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON) — avec ANALYZE, sinon il n’y a ni lignes ni temps réels à comparer.
  2. Collez le résultat complet (le tableau externe convient) dans la zone, puis lancez Analyser le plan.
  3. Lisez d’abord le résumé : nombre de nœuds, coût total le plus élevé, temps d’exécution et lignes renvoyées par la racine.
  4. Parcourez les constats : écarts d’estimation, lignes écartées par un filtre, côtés internes exécutés de nombreuses fois et nœud le plus lent sont ceux qui méritent une action.
  5. Corrigez une chose à la fois (index, réécriture, cible de statistiques), puis relancez le plan pour voir si les chiffres bougent.

Ce que l’analyse signale, ce qu’elle ne voit pas et comment l’utiliser

Ce que l’analyse signale

Le résumé affiche le nombre de nœuds, le Total Cost le plus élevé de l’arbre, le temps d’exécution (Execution Time s’il existe, sinon le nœud le plus lent) et les lignes renvoyées par la racine. L’arbre reprend pour chaque nœud le coût, le temps réel, les lignes, les boucles, l’estimation et la condition d’index ou le filtre.

Les constats comparent Plan Rows aux lignes réellement renvoyées : dès qu’elles diffèrent d’un facteur dix ou plus, le nœud est cité avec les deux valeurs. Sont aussi signalés un filtre ayant écarté au moins dix fois plus de lignes qu’il n’en a renvoyé, un côté interne exécuté mille fois ou plus, et le nœud le plus lent dès 50 ms et au moins un cinquième du temps d’exécution.

Ce qu’elle ne peut pas voir

Un plan sans ANALYZE n’a ni lignes ni temps réels : la page le signale et omet les métriques de temps au lieu d’afficher des zéros ; les contrôles d’estimation sont ignorés pour la même raison. Les compteurs BUFFERS figurent dans le JSON mais ne sont pas interprétés ici, et le JIT, la répartition entre workers parallèles ainsi que le temps des déclencheurs ou fonctions ne sont pas analysés.

Un plan correspond à une exécution : un cache chaud, d’autres statistiques, une valeur de paramètre différente ou une requête préparée réutilisant un plan générique donnent un autre arbre. Comparez des plans pris dans les mêmes conditions et traitez les constats comme des pistes à examiner, pas comme un verdict.

Agir sur le résultat

Un grand écart d’estimation indique souvent des statistiques obsolètes ou un prédicat que le planificateur n’estime pas (fonction sur la colonne, condition corrélée, distribution inhabituelle) ; ANALYZE, une cible de statistiques plus élevée ou une condition réécrite changent le plan avant tout index.

Les lignes écartées par un filtre pointent vers un index absent ou inutilisé et vers un prédicat peu sélectif, tandis qu’un côté interne répété dans une boucle imbriquée est le signe classique d’une jointure qu’un hash join traiterait mieux. Changez une chose, relancez avec les mêmes paramètres et gardez le plan qui gagne sur la charge que vous exécutez réellement.

Outils récents :