Lire un EXPLAIN

Prérequis : cours précédent (index).

Pourquoi

« C'est lent » ne dit pas où. EXPLAIN (ANALYZE, BUFFERS) montre le plan réel : ce que Postgres fait, ligne par ligne, en millisecondes. Cinq minutes de lecture valent des heures d'hypothèses.

Concepts

• EXPLAIN = plan prévu ; ANALYZE = exécute vraiment et montre le réel (attention : écritures exécutées ! Utiliser une transaction rollbackée pour tester un UPDATE/DELETE).
• Lire de bas en haut : les feuilles (scans) alimentent les nœuds (jointures, tris). Le nœud le plus coûteux = le coupable.
• Vocabulaire : Seq Scan (lit tout — suspect n°1 sur grosse table), Index Scan/Bitmap (bien), Nested Loop (ok si petit côté, catastrophe sinon), Hash Join/Merge Join (gros volumes), Sort avec Sort Method: external (tri sur disque = lent, work_mem ?).

Exemple : le diagnostic express

Seq Scan on orders  (cost=... rows=2000000) (actual time=1200ms)
  Filter: (status = 'pending')

Traduction : 2M lignes lues pour quelques centaines utiles → index partiel ON orders(status) WHERE status='pending' → 5 ms.

Cas réel

Rapport à 45 s : EXPLAIN montre un Nested Loop avec 2M de boucles côté interne (index manquant sur la clé de jointure). Un index : 45 s → 800 ms. Sans EXPLAIN, on aurait « optimisé » le code applicatif pour rien.

Pièges

• EXPLAIN sans ANALYZE : le plan prévu ≠ le réel (stats obsolètes → ANALYZE la_table d'abord !).
• ANALYZE sur écriture sans transaction : ça écrit vraiment. BEGIN; EXPLAIN ANALYZE UPDATE…; ROLLBACK;.
• Optimiser le premier nœud venu : toujours le plus coûteux réel, pas le plus laid.

À retenir

ANALYZE + BUFFERS, lecture bas-haut, Seq Scan suspect, stats à jour, tester les écritures en rollback.