1. Le rôle du Planificateur / Optimiseur de requêtes (Cost-Based Optimizer)

Lorsque vous soumettez une requête SQL, le planificateur de PostgreSQL analyse les statistiques de distribution des données et évalue des dizaines de stratégies d’exécution possibles pour retenir celle dont le coût estimé (Cost) est le plus faible.

2. Décoder la commande EXPLAIN ANALYZE

Alors que EXPLAIN ne fournit qu’une estimation théorique, EXPLAIN ANALYZE exécute réellement la requête et mesure les temps effectifs à chaque nœud de l’arbre d’exécution :

EXPLAIN (ANALYZE, BUFFERS, VERBOSE)
SELECT c.nom, COUNT(t.transaction_id), SUM(t.montant_chf)
FROM clients c
JOIN transactions t ON c.client_id = t.client_id
WHERE c.canton = 'VD' AND t.date_transaction >= '2026-01-01'
GROUP BY c.nom;

3. Les nœuds d’exécution critiques à surveiller

  • Seq Scan vs Index Scan / Index Only Scan : Un scan séquentiel sur une table volumineuse indique souvent l’absence d’un index crucial ou un prédicat non sargable.
  • Types de jointures physiques :
    • Nested Loop : Idéal lorsque l’un des jeux de données est très petit et que l’autre est indexé.
    • Hash Join : Le moteur charge la petite table dans une table de hachage en RAM, puis scanne la grande table.
    • Merge Join : Utilisé lorsque les deux tables sont déjà triées sur la clé de jointure.
  • Shared Hit vs Shared Read : Mesure si les données étaient déjà présentes dans la mémoire tampon (RAM buffer pool) ou s’il a fallu solliciter le disque dur.
PreviousNext