11.2. Types d'index
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);
Note
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.