{"id":10697,"date":"2025-05-13T16:20:05","date_gmt":"2025-05-13T15:20:05","guid":{"rendered":"https:\/\/blog.capdata.fr\/?p=10697"},"modified":"2025-05-13T16:29:21","modified_gmt":"2025-05-13T15:29:21","slug":"postgresql-basics-lire-un-plan-dexecution","status":"publish","type":"post","link":"https:\/\/blog.capdata.fr\/index.php\/postgresql-basics-lire-un-plan-dexecution\/","title":{"rendered":"PostgreSQL Basics : lire un plan d’ex\u00e9cution comme un\u00b7e pro (ou presque)"},"content":{"rendered":"\"twitter\"<\/a>\"linkedin\"<\/a>\"mail\"<\/a>

Introduction :<\/h1>\n

Quand une requ\u00eate PostgreSQL est consid\u00e9r\u00e9e comme lente ou que ses performances se d\u00e9gradent soudainement, il y a un r\u00e9flexe \u00e0 toujours avoir : utiliser les plans d’ex\u00e9cution. Je n\u2019apprends certainement rien \u00e0 la majorit\u00e9 des personnes qui liront cet article, mais si cela permet de garder vigilants les d\u00e9butants et de leur enseigner quelques ficelles, alors cet article vaut le coup.<\/p>\n

Si vous avez d\u00e9j\u00e0 \u00e9t\u00e9 dans le cas de figure o\u00f9 un plan d’ex\u00e9cution est trop gros pour que vous sachiez par quel bout le prendre, ou si vous avez l’impression qu’on vous parle chinois quand on \u00e9voque les index scan ou les “cost” d’une requ\u00eate, alors vous \u00eates au bon endroit.<\/p>\n

Dans cet article, premier d’une s\u00e9rie sur les bases de PostgreSQL, nous allons d\u00e9mystifier l’optimisation des requ\u00eates en utilisant EXPLAIN comme point de d\u00e9part, et les plans d’ex\u00e9cution g\u00e9n\u00e9r\u00e9s comme fil conducteur.<\/p>\n

L\u2019objectif : vous aider \u00e0 identifier rapidement les informations cl\u00e9s, rep\u00e9rer les goulots d\u2019\u00e9tranglement, et gagner en autonomie pour diagnostiquer les performances de vos requ\u00eates.<\/p>\n

C\u2019est parti !<\/p>\n

EXPLAIN ANALYZE : c\u2019est quoi exactement et pourquoi l\u2019utiliser ?<\/h2>\n

Pour commencer, il faut savoir qu’un moteur de base de donn\u00e9es, que ce soit PostgreSQL ou un autre ne “lit” pas une requ\u00eate comme un humain pourrait la lire, de gauche \u00e0 droite. Il \u00e9labore plut\u00f4t un plan d’ex\u00e9cution : il cr\u00e9\u00e9 un ensemble d’\u00e9tape qui se veulent le plus optimis\u00e9es possible pour aller chercher les donn\u00e9es que vous lui demander de la fa\u00e7on la plus efficace possible.<\/p>\n

Il y a un moyen simple de voir ce plan d’ex\u00e9cution, c’est d’utiliser la commande EXPLAIN ANALYZE. Elle nous permet en plus de comprendre de quelle fa\u00e7on le moteur \u00e0 r\u00e9ellement ex\u00e9cut\u00e9 notre ordre SQL (et pas seulement comment il pensait le faire). C’est un peu comme lire un journal de bord de l’ex\u00e9cution de la requ\u00eate.<\/p>\n

Prenons un exemple simple :<\/h3>\n

Imaginons que nous avons une table users, constitu\u00e9e comme tel :<\/p>\n

CREATE TABLE users (\r\nid integer PRIMARY KEY,\r\nname vachar(30),\r\nage integer,\r\nemail varchar(80) );<\/pre>\n
Et que nous souhaitons utiliser la requ\u00eate suivante dans notre application :<\/p>\n
SELECT * FROM users WHERE email = 'foo@example.com';<\/pre>\n
Sur cette table, nous n’avons pas d’index. Voici donc ce \u00e0 quoi pourrait ressembler notre plan d’\u00e9xecution si nous utilisons la commande :<\/p>\n
EXPLAIN ANALYZE SELECT * FROM users WHERE email = 'foo@example.com';\r\n\r\nSeq Scan on users (cost=0.00..35.50 rows=1 width=100)\r\nFilter: (email = 'foo@example.com')\r\nRows Removed by Filter: 999\r\nActual time=0.010..0.420 rows=1 loops=1\r\n<\/pre>\n
Les termes du plan d’ex\u00e9cution :<\/h3>\n
A premi\u00e8re vue, il n’est pas \u00e9vident de comprendre tout les termes que l’on voit dans le plan d’ex\u00e9cution g\u00e9n\u00e9r\u00e9.<\/p>\n
Voici un r\u00e9capitulatif des principaux :<\/p>\n