📚 В плане появился external merge Disk. Нужно ли сразу повышать work_mem?

Артефакт:

Sort Method: external merge Disk: 184320kB Buffers: shared hit=42817 read=6932, temp read=23140 written=23208

Это значит: сортировка не поместилась в доступную рабочую память и использовала временное дисковое пространство.

Но это ещё не готовая настройка.

work_mem применяется не один раз на весь запрос. В одном плане могут быть несколько операций:

Sort Hash Hash Join HashAggregate ещё один Sort

Каждая может использовать память отдельно. Плюс есть parallel workers и другие запросы на сервере.

Поэтому опасно делать вывод:

увидели Disk → подняли work_mem глобально

Сначала проверьте:

— какой узел пишет во временные файлы; — сколько строк пришло на вход; — почему промежуточный набор такой большой; — сколько Sort/Hash-операций в плане; — есть ли параллельность; — сколько таких запросов работает одновременно; — какие work_mem и hash_mem_multiplier действуют сейчас.

Disk не равен нужному значению work_mem. temp read и temp written — не размер одного временного файла.

Иногда решение — не память, а более ранний фильтр, другая форма JOIN, проверка DISTINCT или ORDER BY, уменьшение диапазона данных или подходящий индекс.

Но индекс — только диагностическая ветка, не автоматический ответ на любой Sort.

Важно: EXPLAIN ANALYZE реально выполняет запрос. Для DML-команд он реально выполняет изменение данных. На production это нужно оценивать отдельно.

Вывод: временный файл — симптом. Решение выбирают после анализа узла плана, входного объёма, числа операций и конкурентности.

Сохраните признаки, по которым видно, что запрос начал платить диском за сортировку или hash-операции.

🔹🔹🔹🔹