PostgreSQL-Indizierung wird viel einfacher, wenn Sie aufhören, in Begriffen von „Index oder kein Index“ zu denken und anfangen, in Begriffen der Form des Workloads zu denken.
BRIN und GIN sind ein gutes Beispiel, da sie nahezu gegensätzliche Probleme lösen.
Wann BRIN hilft
BRIN ist nützlich für sehr große Tabellen, bei denen die Werte natürlich mit der physischen Reihenfolge der Zeilen korreliert sind, wie zum Beispiel:
- Zeitstempel in Append-Only-Ereignistabellen
- monoton steigende IDs
- Zeitreihendaten
Es speichert leichtgewichtige Zusammenfassungen von Blockbereichen, anstatt jede Zeile einzeln zu indizieren. Deshalb kann es im Vergleich zu einem B-Baum winzig sein.
Wann GIN hilft
GIN ist nützlich, wenn Sie in zusammengesetzten Werten suchen müssen:
jsonb- Arrays
- Volltextdokumente
Es indiziert die enthaltenen Elemente, anstatt den gesamten Wert als einen undurchsichtigen Blob zu behandeln.
Ein praktisches Beispiel
Für eine große Ereignistabelle:
CREATE INDEX events_created_at_brin_idx
ON events
USING BRIN (created_at);
Für eine jsonb-Spalte:
CREATE INDEX users_preferences_gin_idx
ON users
USING GIN (preferences);
Dies sind beides „Indizes“, aber sie verbessern sehr unterschiedliche Arten von Abfragen.
Abwägungen
BRIN ist kompakt und kostengünstig, hängt jedoch von den Ordnungsmerkmalen ab.
GIN ist leistungsfähig, aber normalerweise größer und teurer in der Wartung bei Schreibvorgängen.
Deshalb ist die richtige Frage nicht „welcher ist schneller?“, sondern „welcher passt zu dem Zugriffsmodus?“
Weitere Informationen