Opérations

Accès aux index et aux tables

Seq Scan

L'opération Seq Scan parcourt la relation complète telle qu'elle est stockée sur disque (comme un TABLE ACCESS FULL).

Index Scan

L'opération Index Scan réalise un parcours de B-tree, passe au travers des nœuds feuilles pour trouver toutes les entrées correspondantes, et récupère les données correspondantes de la table. C'est identique à un INDEX RANGE SCAN suivi d'un TABLE ACCESS BY INDEX ROWID. Voir aussi le Chapitre 1, « Anatomie d'un index SQL ».

Les prédicats de filtre d'index causent souvent des problèmes de performances pour un Index Scan. La section suivante explique comment les identifier.

Index Only Scan

L'opération Index Only Scan réalise un parcours du B-tree, puis traverse les nœuds feuilles pour trouver les entrées correspondantes. Il n'est pas nécessaire d'accéder à la table car l'index dispose de toutes les colonnes pour satisfaire la requête (exception : les informations de visibilité). Voir aussi « Parcours d'index seul : éviter l'accès à la table ».

Bitmap Index Scan / Bitmap Heap Scan / Recheck Cond

Le message sur la liste de discussion des performances sur PostgreSQL de Tom Lane est très clair et très précis.

Un Index Scan standard récupère les pointeurs de ligne un par un dans l'index, et visite immédiatement la ligne pointée dans la table. Un parcours de bitmap récupère tous les pointeurs de ligne dans l'index en un coup, les trie en utilisant une structure bitmap en mémoire, puis visite les lignes dans la table dans l'ordre de leur emplacement physique.

— Tom Lane

Jointures

Généralement, les opérations de jointure traitent seulement deux tables à la fois. Au cas où une requête aurait plus de jointures, elles sont traitées séquentiellement : tout d'abord deux tables, puis le résultat intermédiaire avec la table suivante. Dans le contexte des jointures, le terme « table » peut aussi signifier « résultat intermédiaire ».

Nested Loops

Joint deux tables en récupérant le résultat d'une table, et en recherchant chaque ligne de la première table dans la seconde. Voir aussi « Boucles imbriquées ».

Hash Join / Hash

La jointure de hachage charge les enregistrements candidats d'un côté de la jointure dans une table de hachage (marqué avec le mot Hash dans le plan) dont chaque enregistrement est ensuite testé avec l'autre côté de la jointure. Voir aussi « Jointure par hachage ».

Merge Join

La jointure d'assemblage (ou de tri) combine deux listes triées, comme une fermeture Éclair. Les deux côtés de la jointure doivent être pré-triés. Voir aussi « Fusion par tri ».

Tri et regroupement

Sort / Sort Key

Trie l'ensemble de données sur les colonnes mentionnées dans la partie Sort Key. L'opération Sort a besoin d'une grande quantité de mémoire pour matérialiser le résultat intermédiaire (sans pipeline). Voir aussi « Indexer un tri ».

GroupAggregate

Agrège un ensemble pré-trié suivant la clause group by. Cette opération ne place pas de grandes quantités de données (en pipeline). Voir aussi « Indexer le Group By » à la page %p.

HashAggregate

Utilise une table de hachage temporaire pour grouper les enregis­trements. L'opération HashAggregate ne requiert pas de données pré-triées. Elle utilise une grande quantité de mémoire pour matérialiser le résultat intermédiaire (sans pipeline). La sortie n'est pas triée. Voir aussi « Indexer le Group By » à la page %p.

Requêtes Top-N

Limit

Annule les opérations sous-jacentes quand le nombre désiré de lignes a été récupéré. Voir aussi « Récupérer les N premières lignes ».

L'efficacité d'une requête top-N dépend du mode d'exécution des opérations sous-jacentes. C'est très inefficace lors de l'arrêt d'opérations ne fonctionnant pas en pipeline, comme un Sort par exemple.

WindowAgg

Indique l'utilisation de fonctions de fenêtrage. À partir de PostgreSQL version 15, « Run Condition » indique une fin Top-N possible. Voir aussi « Utiliser les fonctions de fenêtrage pour une pagination efficace ».