Чем GIN отличается от GiST? Почему для JSONB и full-text обычно GIN?

Почему для JSONB и full-text обычно GIN

Для jsonb @> и @@ GIN даёт точные совпадения (нет Recheck), тогда как GiST может быть lossy и выполняет дополнительный heap-fetch. GIN быстрее на lookup при большом объёме данных; GiST компактнее, но медленнее на типичных full-text нагрузках.

-- GIN для JSONB: два operator class
-- jsonb_ops (default) — поддерживает @>, ?, ?|, ?&, @?
CREATE INDEX idx_products_attrs_gin ON products USING gin (attributes);

-- jsonb_path_ops — только @> и @?, но компактнее (~3x меньше)
CREATE INDEX idx_products_attrs_path ON products USING gin (attributes jsonb_path_ops);

-- GIN для full-text
CREATE INDEX idx_articles_fts ON articles USING gin (to_tsvector('russian', title || ' ' || body));

-- GiST для tsvector (альтернатива, компактнее, но медленнее поиск)
CREATE INDEX idx_articles_fts_gist ON articles USING gist (to_tsvector('russian', body));

-- GiST для диапазонов дат (GIN не поддерживает range-типы)
CREATE INDEX idx_bookings_period ON bookings USING gist (period);

Архитектура GIN

GIN (Generalized Inverted Index) — обратный индекс: одна строка таблицы может дать много ключей в индексе. PostgreSQL разбивает значение (jsonb-объект, массив, tsvector) на составные элементы, и каждый элемент указывает на список строк, где он встречается.

Структура: B-tree по ключам + posting lists (или posting trees при большом количестве совпадений) для хранения TID-списков строк. GIN отлично работает для:

• jsonb @> (containment), jsonb ? 'key', jsonb @? (jsonpath)
• Массивы: &&, @>, <@
• Full-text: tsvector @@ tsquery

Архитектура GiST

GiST (Generalized Search Tree) — расширяемый framework для построения деревьев с пользовательскими операторами. Каждый leaf-узел хранит bounding box или другой predicate, описывающий множество значений поддерева. При поиске возможны ложные совпадения (lossy), поэтому PostgreSQL перепроверяет строки через heap (Recheck Cond в EXPLAIN).

GiST используется для: геометрии (PostGIS), tsrange/daterange, inet, tsvector, nearest-neighbor (<->).

Fastupdate и pending list в GIN

GIN дорог на запись: добавление одной строки может обновить многие posting lists. Механизм fastupdate накапливает изменения в pending list и применяет их batch-ом (при VACUUM или превышении gin_pending_list_limit).

-- Отключить fastupdate, если нужна немедленная видимость
CREATE INDEX idx_products_gin ON products USING gin (tags) WITH (fastupdate = off);

-- Размер pending list (по умолчанию 4MB)
SET gin_pending_list_limit = '16MB';

-- Принудительно применить pending list
SELECT gin_clean_pending_list('idx_products_gin');

Сравнение для full-text

• GIN: быстрый поиск, нет Recheck, дорогой на запись, большой размер.
• GiST: компактнее, есть Recheck (heap fetch), чуть медленнее поиск. Предпочтителен при высоком write rate и когда read latency не критична.

Подводные камни

• GIN с jsonb_ops индексирует все ключи и значения — на широких документах становится очень большим; jsonb_path_ops меньше, но не поддерживает ?-операторы.
• GiST даёт Recheck — при большом количестве ложных совпадений это дополнительный heap I/O; проверяйте в EXPLAIN ANALYZE.
• GIN fastupdate: при краше без checkpoint pending list может быть не применён — данные не теряются, но индекс временно неполон.
• GIN не поддерживает сортировку (ORDER BY) — для nearest-neighbor нужен GiST или специальные расширения (pgvector: HNSW, IVFFlat).
• pg_trgm расширение добавляет GIN/GiST-операторы для LIKE '%substring%' — частый кейс для автодополнения.
• Размер GIN-индекса можно проверить: SELECT pg_size_pretty(pg_relation_size('idx_name'));
• При высоком write rate с fastupdate=on мониторьте pg_stat_user_indexes и размер pending list через pgstatindex().
• Для range-типов (daterange, tsrange) GIN не поддерживает стандартные операторы — только GiST.

• Выбирать GIN/GiST по названию, а не по оператору.
• Забывать operator class для jsonb.
• Не учитывать write amplification у GIN.

• Просит пример jsonb @>.
• Проверяет понимание inverted index.
• Уточняет recheck в плане.