Визуализатор планов запросов

Распарси EXPLAIN (ANALYZE, FORMAT JSON) в точное дерево узлов — сохраняя структуру родитель/потомок, типы узлов и поля, от которых зависят следующие этапы. Верхний уровень JSON — массив с одним объектом плана; у каждого узла Node Type, Plans (потомки), Startup Cost, Total Cost, Plan Rows, Actual Startup/Total Time, Actual Rows и Loops. Loops — множитель, ломающий или спасающий корректность: внутри nested loop на 1000 итераций Actual Rows указан за цикл, так что суммарные фактические строки = Actual Rows × Loops — смешение даёт ошибку оценки в 1000 раз. Корректно обработай много-потомковые узлы (например, стороны build и probe Hash Join — отдельные массивы потомков, не сливать) и все типы scan/join без схлопывания. Некорректный или не-JSON ввод должен падать с понятным сообщением и подсказкой строки, а не крашем или пустым деревом.

Отрисуй дерево с фактическими против плановых строк и self-time против накопленного времени по каждому узлу, со сворачиванием. Для каждого узла покажи: Plan Rows против суммарных фактических строк (Actual Rows × Loops) и коэффициент ошибки оценки (факт/план), Actual Total Time против self-time. Self-time — собственный вклад узла: `self = Total Time − Σ Total Time потомков` — для листовых узлов (seq scan, index scan) self равен Total Time; у корня Total Time всегда наибольший, но self может быть крошечным, так что показ только Total Time вводит в заблуждение, делая корень всегда похожим на узкое место. Скорректируй строки по циклам, вычисли self-time и сделай дерево сворачиваемым, чтобы большие планы оставались читаемыми. Покажи сигналы латентности и строк рядом, чтобы пользователь видел и 'куда ушло время', и 'где планировщик ошибся сильнее', не смешивая cost (предсказание планировщика) со временем (реальность выполнения).

Подсветь худший узел двумя независимыми сигналами — наибольшей ошибкой оценки (факт/план, с коррекцией по циклам) и наибольшим self-time — показав каждый отдельно, чтобы пользователь видел оба измерения. Сеньорная тонкость — ложные тревоги: ошибка оценки в 100 раз на узле 0,01 мс — шум, а не узкое место. Взвесь тяжесть по self-time (например, `severity = log(error) × self-time` или `error × self-time`), чтобы дешёвые узлы никогда не доминировали. Корректный план без большой ошибки не должен показывать флагов — явно протестируй это. Объясни, почему одна Total Cost — неверный сигнал (это предсказание планировщика, не время выполнения) и почему один self-time пропускает ошибки планировщика (быстрый узел с огромным разрывом оценки сигнализирует об устаревшей статистике или отсутствующем индексе, даже если он не самый медленный).

Определи проливающиеся hash/sort узлы и предложи целевой work_mem — самый полезный инсайт этого инструмента. Hash join и сортировки используют хеш-таблицы в памяти, ограниченные work_mem (по умолчанию 4 МБ на операцию); когда данные превышают его, Postgres сбрасывает на диск партиями (Batches > 1), что типично даёт замедление в 10–100 раз. Покажи: какие узлы пролились (Batches > 1), их Peak Memory Usage если есть (или оценку по числу партий hash при отсутствии) и предложенную нижнюю границу work_mem. Затем порассуждай о компромиссе: слишком высокий work_mem глобально опасен — каждый параллельный запрос может его использовать, так что 100 соединений × 256 МБ = 25 ГБ только на сортировки, риск OOM. Правильный совет — per-query `SET work_mem` для проливающего запроса, а не глобальное повышение. Докажи: фикстура с 10-партийным hash-спиллом флажена, предложенный work_mem показан, не проливающий план без бейджа спилла.

Добавь диффинг план-к-плану и сделай инструмент наблюдаемым в цикле тюнинга. Сравни два EXPLAIN JSON (до/после индекса или фикса статистики) рядом: подсветь какие узлы появились/исчезли, где ошибка оценки и self-time улучшились или ухудшились и где исчез спилл. Затем отработай инцидент: возьми план медленного запроса с seq scan + большим разрывом оценки (устаревшая статистика или отсутствующий индекс), добавь индекс или запусти ANALYZE, повторно EXPLAIN и покажи дифф — seq scan становится index scan, ошибка схлопывается, спилл (если был) исчезает. Снимай лёгкие RED-метрики самого визуализатора (время парсинга, время рендера, число флагов) и задокументируй цикл тюнинга: EXPLAIN → визуализация → фикс (индекс/ANALYZE/work_mem) → повторный EXPLAIN → дифф → проверка отсутствия нового спилла или регрессии. Пост-мортем: каким был сигнал плохого плана, какой фикс применён и что доказывает дифф.