PostgreSQLLa base de données la plus sophistiquée au monde.

11.3. Index multicolonnes

Un index peut porter sur plus d'une colonne d'une table. Par exemple, si vous avez une table de cette forme :

CREATE TABLE test2 (
  majeur int,
  mineur int,
  nom varchar
);

(par exemple, si vous gardez votre répertoire /dev dans une base de données...) et que vous faites fréquemment des requêtes comme :

SELECT nom FROM test2 WHERE majeur = constante AND mineur = constante;

alors il est sans doute souhaitable de définir un index sur les colonnes majeur et mineur ensemble, par exemple avec:,

CREATE INDEX test2_mm_idx ON test2 (majeur, mineur);

Actuellement, seuls les types d'index B-trees et GiST supportent les index multicolonnes. Un maximum de 32 colonnes peut être indexé. Cette limite peut être modifiée à la compilation de PostgreSQL™. Voyez le fichier pg_config_manual.h.

Un index B-tree multicolonnes peut être utilisé avec des conditions de requêtes qui impliquent tout sous-ensemble des colonnes de l'index mais ce dernier est le plus efficace quant il s'agit des contraintes des premières colonnes (celles de gauche). La règle exacte est que les contraintes d'égalité sur les premières colonnes, plus toute contrainte de différence sur la première colonne qui n'a pas une contrainte d'égalité seront utilisées pour limiter la partie parcourue de l'index. Les contraintes sur les colonnes à droite de ces colonnes sont vérifiées dans l'index, donc elles évitent des visites de la table mais elles ne réduisent pas la partie de l'index à parcourir. Par exemple, avec un index sur (a, b, c) et une condition de requête WHERE a = 5 AND b >= 42 AND c < 77, l'index devrait être parcouru à partir de la première entrée avec a = 5 et b = 42 jusqu'à la dernière entrée de a = 5. Les entrées de l'index avec c >= 77 seront passées mais elles devront toujours être parcourues. En principe, cet index pourrait être utilisé pour les requêtes qui ont des contraintes sur b et/ou c sans contrainte sur a -- mais l'index entier devra être parcouru, donc, dans la plupart des cas, le planificateur préférera un parcours séquentiel de la table plutôt que d'utiliser l'index.

Un index GiST multicolonne peut seulement être utilisé quand il existe une condition de requête sur sa colonne de tête. Les conditions sur les colonnes supplémentaires restreignent les entrées renvoyées par l'index mais la condition sur la première colonne est la plus importante pour déterminer à quel point l'index devra être parcouru. Un index GiSTsera relativement inefficace si sa première colonne a seulement quelques valeurs distinctes même s'il y a plein de valeurs distinctes dans les colonnes supplémentaires.

Bien sûr, chaque colonne doit être utilisée avec les opérateurs appropriés au type de l'index ; les clauses qui impliquent d'autres opérateurs ne seront pas pris en compte.

Les index multicolonnes devraient être utilisés avec parcimonie. Dans la plupart des cas, un index sur une seule colonne est suffisant et sauvegarde de l'espace et du temps. Les index avec plus de trois colonnes ont un gros risque d'être inefficace sauf si l'utilisation de cette table est extrêmement stylisée. Voir aussi la Section 11.4, « Combiner des index multiples » pour des discussions sur les mérites des différentes configurations d'index.