EXPLAIN ANALYZE выполняет запрос и показывает дерево узлов с фактическими данными по каждому. Навык чтения сводится к тому, чтобы найти узел, где теряется время, и понять, почему планировщик выбрал именно этот путь. Дерево читается изнутри наружу и снизу вверх: самые вложенные (правые) узлы выполняются первыми, вышестоящие обрабатывают их результат.
Как читать план
- Смотрите на каждый узел пару значений вида actual time=0.05..12.4 rows=1000 loops=1. Первое число – время до первой строки, второе – время до последней; оба указаны на одно выполнение узла.
- Учитывайте loops: если узел выполнялся многократно (вложенный цикл), фактическое суммарное время – это время на проход, умноженное на число проходов. Итоговые строки – rows × loops.
- Сравните оценку и факт. Планировщик пишет ожидаемое число строк (rows= в блоке оценки), ANALYZE – фактическое. Кратное расхождение – главный признак проблемы: устаревшая статистика или неверная оценка селективности ведут к неоптимальному плану.
На что смотреть
Строка Rows Removed by Filter показывает объем прочитанного и отброшенного – кандидат на индекс. Переход Index Scan → Seq Scan на большой таблице часто говорит об устаревшей статистике. Добавьте BUFFERS, чтобы увидеть чтение из кеша против диска:
EXPLAIN (ANALYZE, BUFFERS) SELECT id, name FROM orders WHERE status = 'new';
Чтение отдельного плана показывает срез по одному запросу в моменте. PGLens ранжирует запросы по влиянию на ресурсы и хранит историческую динамику их выполнения, что дает структурированную картину: какие запросы стабильно тяжелые и как их поведение меняется во времени.
