План объясняет, какие физические операции Greenplum выбрал для SQL. Для распределённого запроса важно не только найти сканирование или JOIN, но и понять, где они выполняются, сколько строк передают следующему этапу и как работа делится между сегментами.
Оценка и выполнение
EXPLAIN строит план без выполнения самого запроса. Он показывает оценки оптимизатора: ожидаемое число строк, ширину потока и стоимость операций. Стоимость — условная величина модели, а не время в миллисекундах. Большая оценочная стоимость полезна для сравнения вариантов в одной модели, но не обещает конкретное время ответа.
EXPLAIN ANALYZE действительно выполняет запрос и добавляет фактические показатели. Для SELECT это чтение и вычисления; для изменяющей команды — реальные изменения. Поэтому анализ DML нельзя считать безопасным предварительным просмотром. Выполнение на больших наборах также потребляет обычные ресурсы кластера.
Greenplum использует GPORCA и планировщик на основе PostgreSQL. Форма вывода и названия отдельных операторов могут отличаться. При чтении сначала находят смысл: чтение данных, фильтр, соединение, обмен, агрегация, выдача результата. Не нужно искать единственный обязательный текстовый шаблон для каждого SQL.
Читать от источника к результату
В текстовом дереве родитель обычно расположен выше дочерних операций. Чтобы проследить данные, начинай с нижнего сканирования и двигайся к потребителю его результата. Такая схема может описывать сумму по распределённой таблице:
Aggregate ← окончательный итог
Gather Motion ← частичные итоги в одно место
Aggregate ← локальный итог сегмента
Seq Scan ← строки таблицыЭто схема операторов, а не замер на конкретном кластере. На каждом шаге спрашивай: какие строки вошли, что осталось на выходе и где находится исполнитель? Для суммы локальная агрегация резко уменьшает поток. Для JOIN без подходящего размещения сначала может понадобиться Redistribute или Broadcast.
Обозначения вида N:1 или N:N у Motion описывают отправителей и получателей в данном плане. Это не количество строк. Границы Motion также делят план на slices — части распределённого исполнения, между которыми организован обмен.
Сопоставить оценки с фактом
Оптимизатор выбирает порядок JOIN и способ обмена до того, как увидит полный результат. Если он ожидал небольшой набор, то мог выбрать Broadcast. Если после фильтра фактически осталось намного больше строк, сеть и память получили другую нагрузку, чем предполагала модель.
ANALYZE собирает статистику о данных: размеры, распределение значений, долю NULL и другие сведения для оценок. Это отдельная операция от EXPLAIN ANALYZE. После крупной загрузки или изменения состава таблицы статистика может перестать описывать актуальные данные, даже если сам SQL не изменился.
Проверка не заканчивается командой ANALYZE. Оценка может ошибаться из-за зависимостей между колонками, сложных выражений или особенностей фильтра. Поэтому сравнивают оценки с фактом на нескольких важных этапах, начиная с места, где впервые появляется заметное расхождение.
В распределённом выводе число строк может относиться к одному исполнителю, среднему, максимуму или общему потоку. Читай подпись конкретного поля и число участников. Сравнение среднего по сегментам с общей оценкой без учёта этого масштаба даёт ложный вывод об ошибке в несколько раз.
Skew и самый занятый исполнитель
Средняя нагрузка не показывает, кто задержал завершение этапа. У одного сегмента могло оказаться много строк одного ключа, а остальные закончили раньше. Поэтому полезны максимум строк, время и номер исполнителя вместе со средними значениями.
Перекос может возникнуть в исходной таблице, после фильтра или после Motion. Если таблица равномерна, а перераспределение по другому ключу собрало частое значение на одном сегменте, исправлять нужно этот этап и его вход. Проверка только дискового размера исходной таблицы здесь не поможет.
Время узлов дерева нельзя бездумно сложить: операции перекрываются по времени, а показатели могут включать работу дочерних узлов или ожидание. Медленный оператор выше по дереву иногда ждёт данные снизу. Сопоставляй времена с движением строк и состоянием участников, а не выбирай проблему по самой большой цифре.
Память и spill
JOIN, сортировка и агрегация используют память. Если рабочий набор не помещается, некоторые операторы создают временные файлы на диске. Это spill: дополнительная запись и чтение вместо выполнения целиком в памяти. Диск и ограничения временных файлов могут стать причиной замедления или ошибки.
Spill не доказывает, что нужно немедленно увеличить память всему кластеру. Сначала проверяют объём после фильтров, ширину потока, ошибку оценки и skew. Один перегруженный сегмент может писать временные файлы, пока другие почти не используют выделенные ресурсы. Избыточная конкуренция запросов также меняет доступный бюджет.
Для диагностики выбирают один характерный запрос и сохраняют исходный план, результат и условия нагрузки. Затем меняют одну причину — например, статистику или ранний фильтр — и сравнивают повторно. Корректность результата обязательна: быстрый план с потерянными строками не является оптимизацией. Ожидание до начала исполнения отдельно разберём в уроке ресурсных групп.