Les types d'index Postgres ne sont utiles que lorsqu'ils correspondent au modèle de requête_
Le B-tree est le choix par défaut pour une raison, mais PostgreSQL dispose d'autres types d'index pour les recherches d'égalité, la recherche de documents, la géométrie et d'autres modèles d'accès spécialisés.
“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.