Запрос с JOIN тормозит на 5 секунд, EXPLAIN внутри — помогите разобраться

[cohenst1]

PostgreSQL 16, таблица orders ~12 млн строк, делаю JOIN с users по user_id и фильтр по created_at за последний месяц. Запрос 5 секунд. В EXPLAIN вижу Seq Scan на orders, хотя индекс на created_at есть. Почему не используется?

[qawsqaws]

Скинь полный EXPLAIN ANALYZE, а не просто план. Без него гадаем. Но навскидку: если фильтр выбирает большую долю таблицы, планировщик сознательно выберет seq scan, это нормально.

[asynclover]

За месяц это примерно 1.5 млн строк из 12 млн. То есть 12%.

[qcdeed]

Вот и ответ. 12% — это уже та зона где seq scan часто выгоднее random access по индексу. Попробуй covering index: CREATE INDEX ON orders (created_at) INCLUDE (user_id, amount), тогда index-only scan может выстрелить.

[jbosco]

Плюс проверь когда последний раз бегал ANALYZE по таблице. Кривая статистика — причина половины подобных кейсов. И посмотри на work_mem, если идёт hash join с диском на temp, оно само по себе даст секунды.

[ansiblemain]

Ещё классика: created_at у тебя точно timestamp, а не timestamptz, и в запросе нет неявного приведения типов? Каст по колонке убивает индекс моментально.

[FpgaDev]

О, work_mem стоит дефолтные 4MB. Поднял до 64MB на сессию — запрос упал до 800мс. Hash join перестал уходить на диск. Спасибо, не думал что так сильно влияет!

[RedisNinja]

Вот-вот. Дефолтный work_mem 4MB — это наследие времён когда сервера были с 1GB RAM. Но не ставь его глобально в гигабайты, он же на каждую операцию сортировки, прибьёшь память при конкурентных запросах.

[rust_sre]

@qcdeed, covering index хорошая идея, но стоит уточнить: index-only scan сработает только если visibility map актуальна, то есть VACUUM прошёл по страницам достаточно недавно. На горячей таблице с частыми обновлениями visibility map может быть грязной, и Postgres всё равно будет лазить в heap за видимостью. Можно проверить через pg_stat_user_tables: колонка n_live_tup vs heap_blks_hit после создания индекса покажет, используется ли он реально без heap.

[jpearce]

@FpgaDev, с work_mem важно не забыть: SET work_mem = '64MB' на сессию — это нормально для отладки, но если поднять глобально, то при 100 одновременных коннектах с несколькими операциями сортировки каждый это 100 * несколько * 64MB. На боевом сервере лучше либо выставлять в BEGIN...COMMIT для конкретных тяжёлых запросов, либо использовать параметр на уровне роли/пользователя для аналитических запросов, а не на всём инстансе.