BRIN und GIN sind wichtig, weil sie sehr unterschiedliche Workloads optimieren_

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

• PostgreSQL BRIN
• PostgreSQL GIN
• PostgreSQL Indexarten