PostgreSQL™ propose plusieurs types d'index : B-tree, Hash, 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éera un index B-tree, ce qui convient dans la plupart des situations. Les index B-tree savent traiter les égalités et les recherches sur des tranches de valeurs des données qui peuvent être triées. En particulier, l'optimiseur de requêtes de PostgreSQL™ essaie d'utiliser un index B-tree lorsque 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 implémentées avec une recherche par index B-tree (mais notez que IS NULL n'est pas équivalent à = et n'est pas indexable).
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'. Néanmoins, si votre serveur n'utilise pas la locale C, il vous faudra créer l'index avec une classe d'opérateur spéciale pour supporter l'indexage à correspondance de modèles. Voir la Section 11.8, « Classes d'opérateurs » ci-dessous. Il est aussi possible d'utiliser des index B-tree pour ILIKE et ~* mais seulement si le modèle commence avec des caractères non alphabétiques, c'est-à-dire des caractères non affectés par les conversions majuscules/minuscules.
Les index hash peuvent seulement gérer des comparaisons d'égalité simple. Le planificateur de requêtes considérera 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 tests ont montré que les index hash de PostgreSQL™ ne réalisent pas mieux que les index B-tree. La taille de l'index et son temps de construction sont bien pires. De plus, les opérations d'index hash ne sont pas tracées par les WAL, donc les index hash peuvent avoir besoin d'être reconstruit avec REINDEX après un crash de la base. Pour ces raisons, l'utilisation des index hash est découragée.
Les index GiST ne sont pas un seul type d'index mais plutôt une infrastructure à l'intérieur duquel plusieurs stratégies d'indexage peuvent être implémentées. De cette façon, les opérateurs particuliers avec lesquels un index GiST peut être utilisé varient suivant la stratégie d'indexage (la classe d'opérateur). Comme exemple, la distribution standard de PostgreSQL™ inclut des classes d'opérateur GiST pour plusieurs types de données géométiques à deux dimensions, qui supportent des requêtes indexées utilisant ces opérateurs :
<< |
&< |
&> |
>> |
<<| |
&<| |
|&> |
|>> |
@> |
<@ |
~= |
&& |
Voir la Section 9.10, « Fonctions et opérateurs géométriques » pour connaître la signification de ces opérateurs. 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 50, Index GiST.
Les index GIN sont des index inversés qui peuvent gérer des valeurs contenant plus d'une clé, les tableaux par exemple. Comme GiST, GIN peut supporter plusieurs stratégies différentes d'indexage définies par l'utilisateur. Les opérateurs particuliers avec lesquels un index GIN peut être utilisé varient suivant la stratégie d'indexage. Comme 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.14, « Fonctions et opérateurs de tableaux » pour la signification de ces opérateurs.) Les autres classes d'opérateurs GIN sont disponibles dans les modules contrib tsearch2 et intarray. Pour plus d'informations, voir Chapitre 51, Index GIN.