PostgreSQL индексы не используются почему и как починить

[vitaly_quant]

Есть таблица orders на ~50 млн строк, на колонке status есть btree-индекс. Делаю простой SELECT * FROM orders WHERE status = 'pending' — и EXPLAIN ANALYZE показывает Seq Scan, индекс вообще не трогается. Версия PostgreSQL 15.3. Что я делаю не так и как заставить планировщик использовать индекс?

[elena_msk]

Первым делом смотри на селективность. Если у тебя 'pending' это 40% строк — планировщик совершенно справедливо решит, что дешевле сканировать всю таблицу, чем скакать по индексу. Индексы хорошо работают, когда ты достаёшь малый процент строк, обычно это до 5-10%.

[savva_io]

Ещё классика: статистика устарела. Запусти ANALYZE orders и повтори EXPLAIN. Если давно не делали autovacuum или таблица сильно менялась, планировщик может жить в иллюзиях о распределении данных.

[clouddns1959]

Проверь параметр enable_seqscan — надеюсь, он не выключен где-то в конфиге ради «ускорения». Видел такое у людей, которые нагуглили совет без понимания. Для диагностики можно SET enable_seqscan = off локально в сессии, посмотреть стоимость плана с индексом — если она выше seq scan, то планировщик прав.

[vlad_rust]

Развёрнуто по теме: pg_stats это твой друг. Запрос SELECT n_distinct, correlation FROM pg_stats WHERE tablename = 'orders' AND attname = 'status' покажет, сколько уникальных значений видит планировщик и насколько физически отсортированы данные. Если n_distinct маленький (например, 5 статусов), а одно значение занимает 40%+ строк — это объясняет seq scan. Решения: 1) Для колонок с малым количеством уникальных значений попробуй partial index: CREATE INDEX idx_orders_pending ON orders (created_at) WHERE status = 'pending' — он будет маленьким и реально будет использоваться для pending-запросов. 2) Если нужен весь диапазон статусов — рассмотри секционирование по status. 3) Убедись что тип данных в запросе совпадает с типом колонки — неявный каст убивает индекс. 4) VACUUM ANALYZE после массовых UPDATE/DELETE обязателен.

[dnscache8196]

Кстати, если делаешь SELECT *, то даже при хорошем индексе Postgres иногда предпочтёт seq scan, потому что index scan + heap fetch дороже, чем просто пройтись по таблице с bitmap. Попробуй выбирать только нужные колонки — иногда это меняет план.

[olga_code]

Покажи вывод EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT) — без этого гадаем на кофейной гуще. Особенно интересны строки Rows Removed by Filter и actual rows vs estimated rows.