🔒Открыть пост
и посмотреть медиа
и посмотреть медиа
BRIN-индекс в 4570 раз меньше B-tree, пока не обновили 5 % строк
Индекс BRIN в PostgreSQL хранит только min и max колонки на диапазон страниц и весит килобайты, что удобно для логов и событий. Инженер, делавший такие же zonemaps в Oracle, измерил на 10 млн строк, что с BRIN делают обычные UPDATE. Ломается он тихо.
Свежий BRIN по created_at весит 48 КБ против 214 МБ у B-tree и отдаёт день за 21,2 мс (1536 страниц). После обновления 5 % строк тот же запрос читает 51 268 страниц и идёт 558,7 мс: 3,8 млн строк достаются и отбрасываются проверкой.
Причина в MVCC: UPDATE кладёт новую версию строки туда, где есть место. Одна январская строка в «мартовском» диапазоне из 128 страниц расширяет его min/max, и он совпадает с любым январским запросом. А pg_stats.correlation ещё показывает 0,921.
Проверьте у себя: в EXPLAIN (ANALYZE, BUFFERS) смотрите на Heap Blocks: lossy, корреляция ничего не покажет. Лечит CLUSTER, но с блокировкой таблицы. Скрипт есть в статье.
#postgresql #sql
