4.5.2. Utilisation des index

Habituellement, les index accélèrent l'accès aux données de façon transparente : une fois les index créés, le planificateur de requêtes décide de manière transparente quand utiliser l'index pour accélérer le plan de requête. Hélas, le planificateur de requête de PostgreSQL n'optimise pas bien l'utilisation d'index GiST, donc parfois les recherches qui devraient utiliser les index spatiaux par défaut au lieu d'un parcours séquentiel sur la table entière ne sont pas utilisés.

Si vous constatez que vos index spatiaux ne sont pas utilisés (ou vos index sur les champs, par exemple) il y a quelques "trucs" que vous pouvez tenter :

• Premièrement, assurez vous que les statistiques sont bien au courant du nombre et des distributions de valeurs dans une table, pour fournir de meilleures informations au planificateur de requêtes afin qu'il soit apte à prendre la décision d'utiliser ou non l'index. Pour les installations de PostgreSQL 7.4 et inférieur ceci est fait en exécutant : update_geometry_stats([nom_de_la_table, nom_de_colonne]) (calcul la distribution) et VACUUM ANALYZE [nom_de_la_table] [nom_de_colonne] (calcul le nombre de valeurs). À partir de PostgreSQL 8.0, exécuter VACUUM ANALYZE suffit pour effectuer les deux opérations. De toute manière, vous pouvez régulièrement nettoyer votre base de données - plusieurs administrateurs de base de données PostgreSQL exécutent dans leur crontab un nettoyage via VACUUM.
• Si le nettoyage ne fonctionne pas, vous pouvez obliger le planificateur de requêtes à utiliser l'index en utilisant la commande : SET ENABLE_SEQSCAN=OFF. Vous devez utiliser cette commande avec parcimonie, et uniquement des requêtes spatialement indexées : plus généralement, le planificateur de requêtes connait mieux que vous lorsqu'il faut utiliser normalement l'arbre B. Une fois que vous avez effectué votre requête, vous pouvez réaffecter la valeur initiale de ENABLE_SEQSCAN, de sorte que les autres requêtes utiliseront normalement le planificateur.

Note :
Comme pour la version 0.6, il n'est pas nécessaire de forcer le planificateur à utiliser l'index avec ENABLE_SEQSCAN.

Si vous constatez que le planificateur a tort à propos du cout d'un parcours séquentiel par rapport à l'index, essayez de réduire la valeur du paramètre random_page_cost dans votre postgresql.conf ou utilisez la commande SET random_page_cost=#. La valeur par défaut pour ce paramètre est 4, essayez d'y attribuer les valeurs 1 ou 2. Décrémenter cette valeur rend le planificateur plus enclin à utiliser les parcours via l'index.