PostgreSQL™ propose plusieurs types d'index : B-tree, Hash, GiST, SP-GiST et GIN. Chaque type d'index utilise un algorithme différent qui convient à un type particulier de requêtes. Par défaut, la commande CREATE INDEX crée un index B-tree, ce qui convient dans la plupart des situations. Les index B-tree savent traiter les requêtes d'égalité et par tranches sur des données qu'il est possible de trier. En particulier, l'optimiseur de requêtes de PostgreSQL™ considère l'utilisation d'un index B-tree lorsqu'une colonne indexée est utilisée dans une comparaison qui utilise un de ces opérateurs :
< |
<= |
= |
>= |
> |
Les constructions équivalentes à des combinaisons de ces opérateurs, comme BETWEEN et IN, peuvent aussi être implantées avec une recherche par index B-tree. Une condition IS NULL ou IS NOT NULL sur une colonne indexée peut aussi être utilisé avec un index B-tree.
L'optimiseur peut aussi utiliser un index B-tree pour des requêtes qui utilisent les opérateurs de recherche de motif LIKE et ~ si le motif est une constante et se trouve au début de la chaîne à rechercher -- par exemple, col LIKE 'foo%' ou col ~ '^foo', mais pas col LIKE '%bar'. Toutefois, si la base de données n'utilise pas la locale C, il est nécessaire de créer l'index avec une classe d'opérateur spéciale pour supporter l'indexation à correspondance de modèles. Voir la Section 11.9, « Classes et familles d'opérateurs » ci-dessous. Il est aussi possible d'utiliser des index B-tree pour ILIKE et ~*, mais seulement si le modèle débute par des caractères non alphabétiques, c'est-à-dire des caractères non affectés par les conversions majuscules/minuscules.
Les index B-tree peuvent aussi être utilisés pour récupérer des données triées. Ce n'est pas toujours aussi rapide qu'un simple parcours séquentiel suivi d'un tri mais c'est souvent utile.
Les index hash ne peuvent gérer que des comparaisons d'égalité simple. Le planificateur de requêtes considère l'utilisation d'un index hash quand une colonne indexée est impliquée dans une comparaison avec l'opérateur =. La commande suivante est utilisée pour créer un index hash :
CREATE INDEX nom ON table USING hash (column);
Les opérations sur les index de hachage ne sont pas tracées par les journaux de transactions. Il est donc généralement nécessaire de les reconstruire avec REINDEX après un arrêt brutal de la base de données si des modifications n'ont pas été écrites. De plus, les modifications dans les index hash ne sont pas répliquées avec la réplication Warm Standby après la sauvegarde de base initiale, donc ces index donneront de mauvaises réponses aux requêtes qui les utilisent. Pour ces raisons, l'utilisation des index hash est actuellement déconseillée.
Les index GiST ne constituent pas un unique type d'index, mais plutôt une infrastructure à l'intérieur de laquelle plusieurs stratégies d'indexage peuvent être implantées. De cette façon, les opérateurs particuliers avec lesquels un index GiST peut être utilisé varient en fonction de la stratégie d'indexage (la classe d'opérateur). Par exemple, la distribution standard de PostgreSQL™ inclut des classes d'opérateur GiST pour plusieurs types de données géométriques à deux dimensions, qui supportent des requêtes indexées utilisant ces opérateurs :
<< |
&< |
&> |
>> |
<<| |
&<| |
|&> |
|>> |
@> |
<@ |
~= |
&& |
Voir la Section 9.11, « Fonctions et opérateurs géométriques » pour connaître la signification de ces opérateurs. De plus, une condition IS NULL sur une colonne d'index peut être utilisée avec un index GiST. Beaucoup de classes d'opérateur GiST sont disponibles dans l'ensemble des contrib ou comme projet séparé. Pour plus d'informations, voir Chapitre 53, Index GiST.
Les index GiST sont aussi capables d'optimiser des recherches du type « voisin-le-plus-proche » (nearest-neighbor), comme par exemple :
SELECT * FROM places ORDER BY location <-> point '(101,456)' LIMIT 10;
qui trouve les dix places les plus proches d'une cible donnée. Cette fonctionnalité dépend de nouveau de la classe d'opérateur utilisée.
Les index SP-GiST, tout comme les index GiST, offrent une infrastructure qui supporte différents types de recherches. SP-GiST permet l'implémentation d'une grande étendue de structures de données non balancées, stockées sur disque comme les quadtrees, les arbres k-d, et les arbres suffixes. PostgreSQL™ inclut les classes d'opérateur SP-GiST pour les points à deux dimensions, qui supportent les requêtes indexées en utilisant les opérateurs suivants :
<< |
>> |
~= |
<@ |
<^ |
>^ |
(Voir Section 9.11, « Fonctions et opérateurs géométriques » pour la signification de ces opérateurs.) Pour plus d'informations, voir ???.
Les index GIN sont des index inversés qui peuvent gérer des valeurs contenant plusieurs clés, les tableaux par exemple. Comme GiST et SP-GiST, GIN supporte différentes stratégies d'indexation utilisateur. Les opérateurs particuliers avec lesquels un index GIN peut être utilisé varient selon la stratégie d'indexation. Par exemple, la distribution standard de PostgreSQL™ inclut des classes d'opérateurs GIN pour des tableaux à une dimension qui supportent les requêtes indexées utilisant ces opérateurs :
<@ |
@> |
= |
&& |
Voir Section 9.18, « Fonctions et opérateurs de tableaux » pour la signification de ces opérateurs. Beaucoup d'autres classes d'opérateurs GIN sont disponibles dans les modules contrib ou dans des projets séparés. Pour plus d'informations, voir Chapitre 55, Index GIN.