Продолжение анализа производительности для той же СУБД . 80% ожиданий: Текст запроса содержит параметр, поэтому для анализа возможных вариантов оптимизации придется воспользоваться планом выполнения запроса, полученному из отчетов pgpro_pwr: Основная проблема - "декартово произведение" из-за нескольких LEFT JOIN.
Аналогичная задача
Продолжение анализа производительности для той же СУБД .
Инцидент производительности СУБД
Операционная скорость и ожидания СУБД
Корреляция и ожидания СУБД
Ожидания типа IPC
80% ожиданий:
- BgWorkerShutdown
- ParallelFinish
- ExecuteGather
Ожидания типа IPC по SQL-запросам
Следующий SQL-запрос для оптимизации : -1701015661318396920
Текст запроса содержит параметр, поэтому для анализа возможных вариантов оптимизации придется воспользоваться планом выполнения запроса, полученному из отчетов pgpro_pwr:
- pgpro_pwr_queryid: e864c744b5bda408
- plan_id: b8b72054c691886a
План выполнения запроса
Возможная оптимизация SQL-запроса
1. Оптимизация структуры запроса
Основная проблема - "декартово произведение" из-за нескольких LEFT JOIN.
2. Добавление недостающих индексов
3. Оптимизация текущего запроса
4. Настройка PostgreSQL
Возможный план оптимизации
- Добавление индекса для plans_table4 - это самое слабое место в текущем плане
- Разделить запрос на несколько - это даст наибольший прирост производительности
- Использование агрегацию через JSON, если нужны все данные в одной строке
- Настройка параметров СУБД