L'indexation PostgreSQL devient beaucoup plus simple une fois que vous cessez de penser en termes de « index ou pas d'index » et commencez à penser en termes de forme de charge de travail.
BRIN et GIN sont un bon exemple car ils résolvent presque des problèmes opposés.
Quand BRIN Aide
BRIN est utile pour des tables très volumineuses où les valeurs sont naturellement corrélées à l'ordre physique des lignes, telles que :
- timestamps dans les tables d'événements en ajout uniquement
- identifiants en augmentation monotone
- données de séries temporelles
Il stocke des résumés légers des plages de blocs plutôt que d'indexer chaque ligne individuellement. C'est pourquoi il peut être minuscule par rapport à un B-arbre.
Quand GIN Aide
GIN est utile lorsque vous devez rechercher à l'intérieur de valeurs composites :
jsonb- tableaux
- documents en texte intégral
Il indexe les éléments contenus plutôt que de traiter la valeur entière comme un blob opaque.
Un Exemple Pratique
Pour une grande table d'événements :
CREATE INDEX events_created_at_brin_idx
ON events
USING BRIN (created_at);
Pour une colonne jsonb :
CREATE INDEX users_preferences_gin_idx
ON users
USING GIN (preferences);
Ce sont tous deux des « index », mais ils améliorent des types de requêtes très différents.
Échange de Compromis
BRIN est compact et bon marché, mais dépend des caractéristiques d'ordre.
GIN est puissant, mais généralement plus grand et plus coûteux à maintenir lors des écritures.
C'est pourquoi la bonne question n'est pas « lequel est plus rapide ? » mais « lequel correspond au modèle d'accès ? »
Lectures Complémentaires