Детально разобрать план через EXPLAIN (ANALYZE, BUFFERS, SETTINGS, WAL)
PostgreSQLПроизводительностьКоманда
-- ANALYZE really executes the statement: run DML inside a transaction and roll it back
BEGIN;
EXPLAIN (ANALYZE, BUFFERS, SETTINGS, WAL, VERBOSE)
UPDATE customer SET balance = balance + 1 WHERE city = 'Ankara';
ROLLBACK;
-- For SELECT
EXPLAIN (ANALYZE, BUFFERS, SETTINGS)
SELECT name FROM customer ORDER BY name DESC LIMIT 10 OFFSET 1000;Что делает
Возвращает план с реальной статистикой выполнения: BUFFERS показывает shared hit/read/dirtied и временные блоки по каждому узлу, SETTINGS — параметры со значениями не по умолчанию, влияющие на планирование, WAL — сгенерированные записи/байты WAL.
Когда использовать
Чтобы проанализировать разрыв между оценочным и фактическим числом строк, сортировки/хэши, сбрасываемые на диск (Sort Method: external merge, temp read/written), и стоимость DML в WAL.
Внимание
ANALYZE действительно выполняет оператор; DML всегда запускайте внутри BEGIN/ROLLBACK (триггеры и приращения последовательностей всё равно срабатывают). Советы по чтению: разрыв в 10 раз и более между оценочным 'rows' и 'actual rows' указывает на проблему статистики; для узлов внутри циклов время и строки указаны на один цикл — для итога умножайте на loops; высокое 'Heap Fetches' в Index Only Scan означает устаревшую visibility map, а 'Workers Planned' > 'Workers Launched' — исчерпанный пул рабочих процессов. Где накладные расходы на замер времени высоки, используйте TIMING OFF; COSTS OFF также скрывает раздел JIT.
Связанные материалы
- Найти самые дорогие запросы (pg_stat_statements: общее и среднее время)
- Найти запросы, создающие дисковый I/O, временные файлы и WAL (pg_stat_statements)
- Сбросить статистику pg_stat_statements (полностью или для одного запроса)
- Журналировать планы выполнения медленных запросов через auto_explain
- Выявить регрессии планов по queryid (сравнение снимков pg_stat_statements)
- Проверить ёмкость параллельных запросов и текущее использование рабочих процессов