В настоящее время поддерживаются следующие типы параллельного сканирования таблиц.

Другие типы сканирования, такие как сканирование индексов, отличных от btree, могут поддерживать параллельное сканирование в будущем.

Как и в непараллельном плане, ведущая таблица может быть объединена с одной или несколькими другими таблицами с использованием метода вложенного цикла (nested loop), соединения по хешу (hash join) или соединения слиянием (merge join). Внутренняя сторона соединения может представлять собой любой тип непараллельного плана, поддерживаемый планировщиком, при условии, что его запуск безопасен внутри параллельного рабочего процесса. В зависимости от типа соединения, внутренняя сторона также может быть параллельным планом.

Digital Q.DataBase поддерживает параллельную агрегацию, выполняя агрегирование в два этапа. Сначала каждый процесс, участвующий в параллельной части запроса, выполняет шаг агрегации, формируя промежуточный результат для каждой группы, обрабатываемой этим процессом. Это отражается в плане запроса как узел Partial Aggregate узел. Во-вторых, промежуточные результаты передаются ведущему процессу через Gather или Gather Merge. Наконец, ведущий процесс повторно агрегирует результаты, полученные от всех рабочих процессов, для формирования окончательного результата. Это отражается в плане как узел Finalize Aggregate узел.

Поскольку Finalize Aggregate узел выполняется в ведущем процессе, запросы, формирующие относительно большое количество групп по сравнению с количеством входных строк, будут расцениваться планировщиком запросов как менее эффективные. Например, в худшем случае количество групп, обрабатываемых узлом Finalize Aggregate , может достигать количества входных строк, обработанных всеми рабочими процессами на Partial Aggregate этапе. В таких случаях параллельная агрегация явно не обеспечит прироста производительности. Планировщик запросов учитывает это при планировании и с низкой вероятностью выберет параллельную агрегацию в данном сценарии.

Параллельная агрегация поддерживается не во всех ситуациях. Каждая агрегатная функция должна быть безопасен для параллельного выполнения и должен иметь функцию объединения (combine function). Если агрегат имеет состояние перехода типа internal, он должен иметь функции сериализации и десериализации. Подробнее см. CREATE AGGREGATE . Параллельная агрегация не поддерживается, если какой-либо вызов агрегатной функции содержит предложение DISTINCT или ORDER BY , а также не поддерживается для агрегатов упорядоченных наборов или когда запрос использует GROUPING SETS. . Это может быть использовано только в том случае, когда все участвующие в запросе соединения также являются частью параллельной части плана.

В случаях, когда Digital Q.DataBase необходимо объединить строки из нескольких источников в один результирующий набор, используется Append или MergeAppend узел плана. Обычно это происходит при реализации оператора UNION ALL или при сканировании секционированной таблицы. Такие узлы могут использоваться в параллельных планах так же, как и в любом другом плане. Однако в параллельном плане планировщик может вместо этого использовать Параллельный узел Append узел.

Когда узел Append используется в параллельном плане, каждый процесс будет выполнять дочерние планы в том порядке, в котором они указаны, так что все участвующие процессы совместно выполняют первый дочерний план до его завершения, а затем примерно в одно и то же время переходят ко второму плану. Когда вместо этого используется Параллельный узел Append , исполнитель распределяет участвующие процессы как можно более равномерно по своим дочерним планам, чтобы несколько дочерних планов выполнялись одновременно. Это позволяет избежать конкуренции, а также исключает затраты на запуск дочернего плана в тех процессах, которые его никогда не выполняют.

Кроме того, в отличие от обычного узла Append , который может иметь только частичные дочерние узлы при использовании в параллельном плане, узел Parallel Append узел может содержать как частичные, так и полные дочерние планы. Полные дочерние планы будут обрабатываться только одним процессом, так как многократное сканирование привело бы к дублированию результатов. Таким образом, планы, включающие объединение нескольких наборов результатов, могут обеспечивать крупноблочный параллелизм даже при отсутствии эффективных частичных планов. В качестве примера рассмотрим запрос к секционированной таблице, который может быть эффективно выполнен только с использованием индекса, не поддерживающего параллельное сканирование. Планировщик может выбрать Parallel Append обычных Index Scan планов; каждое отдельное сканирование индекса должно быть полностью выполнено одним процессом, но при этом различные сканирования могут выполняться одновременно различными процессами.

enable_parallel_append может использоваться для отключения данной функции.

Если запрос, для которого ожидается такое поведение, не формирует параллельный план, можно попытаться уменьшить значение parallel_setup_cost или parallel_tuple_cost. Разумеется, такой план может оказаться медленнее, чем последовательный план, выбранный планировщиком, однако так будет не всегда. Если параллельный план не создается даже при очень малых значениях этих параметров (например, после установки обоих значений в ноль), возможно, существует причина, по которой планировщик запросов не может сформировать параллельный план для данного запроса. См. Раздел 2.12.2 так и Раздел 2.12.4 для получения информации о возможных причинах такой ситуации.

При выполнении параллельного плана можно использовать команду EXPLAIN (ANALYZE, VERBOSE) для отображения статистики по каждому рабочему процессу для каждого узла плана. Это может быть полезно для определения того, равномерно ли распределяется нагрузка между всеми узлами плана, и в целом для понимания характеристик производительности выбранного плана.