“Ajouter un index” n'est pas un mauvais conseil. C'est un conseil incomplet.
La véritable question est : quel type de recherche cherchez-vous à optimiser ?
PostgreSQL prend en charge plusieurs types d'index car tous les modèles de requête ne se ressemblent pas. Un bon choix d'index suit le modèle d'accès plutôt que de se fier aveuglément à ce qui est le plus facile à générer depuis l'interface graphique.
Commencez par la Requête
Demandez-vous ce que fait réellement la requête :
- recherche d'égalité
- scan de plage
- recherche en texte intégral
- proximité géométrique
- appartenance à un document
Cette question devrait précéder le type d'index.
B-Tree est le Choix par Défaut, Pas la Réponse Universelle
Le B-tree est polyvalent et convient généralement à :
- l'égalité
- l'ordonnancement
- les plages
C'est pourquoi il est le choix par défaut.
Mais d'autres cas nécessitent d'autres outils. Par exemple, GiST devient pertinent pour les recherches géométriques et de proximité, tandis que GIN convient souvent beaucoup mieux aux modèles de documents et de recherche en texte intégral.
Cette différence devient concrète très rapidement :
CREATE INDEX articles_search_idx
ON articles
USING GIN (to_tsvector('english', title || ' ' || body));
Cela résout un problème différent d'un simple B-tree sur created_at.
L'Habitude Ingénierie Qui Évolue
Ne mémorisez pas d'abord des types d'index exotiques. Mémorisez le flux de travail :
- inspectez le modèle de requête
- inspectez le plan d'exécution
- choisissez le type d'index qui correspond au travail réel
Cela maintient l'indexation ancrée dans des preuves plutôt que dans du folklore.
Lectures Complémentaires