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

[demid_bit]

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

[mlai7748]

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

[semyon_null56]

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

[codelinux601]

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

[ruslan_crypto19]

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

[kirill_byte]

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

[alina_linux]

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

[kolya6211]

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