當最佳化器確定平行查詢是特定查詢最快的執行策略時，它將建立一個包含 Gather 或 Gather Merge 節點的查詢計畫。 這是一個簡單的範例

EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
                                     QUERY PLAN
-------------------------------------------------------------------​------------------
 Gather  (cost=1000.00..217018.43 rows=1 width=97)
   Workers Planned: 2
   ->  Parallel Seq Scan on pgbench_accounts  (cost=0.00..216018.33 rows=1 width=97)
         Filter: (filler ~~ '%x%'::text)
(4 rows)

在所有情況下，Gather 或 Gather Merge 節點都只有一個子計畫，該子計畫是將平行執行的計畫部分。 如果 Gather 或 Gather Merge 節點位於計畫樹的最頂端，則整個查詢將平行執行。 如果它位於計畫樹中的其他位置，則只有它下面的計畫部分將平行執行。 在上面的範例中，查詢僅存取一個資料表，因此除了 Gather 節點本身之外，只有一個計畫節點；由於該計畫節點是 Gather 節點的子節點，因此它將平行執行。

使用 EXPLAIN，您可以查看規劃器選擇的工作者數量。 在查詢執行期間到達 Gather 節點時，實作使用者會話的程序將請求與規劃器選擇的工作者數量相等的 背景工作程序數量。 規劃器將考慮使用的背景工作程序數量最多限制為 max_parallel_workers_per_gather。 可以同時存在的背景工作程序總數受到 max_worker_processes 和 max_parallel_workers 的限制。 因此，平行查詢可能以少於計畫的工作者數量執行，甚至根本沒有工作者。 最佳計畫可能取決於可用的工作者數量，因此這可能會導致查詢效能不佳。 如果這種情況經常發生，請考慮增加 max_worker_processes 和 max_parallel_workers，以便可以同時執行更多工作者，或者減少 max_parallel_workers_per_gather，以便規劃器請求更少的工作者。

為給定的平行查詢成功啟動的每個背景工作程序都將執行計畫的平行部分。 領導者也將執行計畫的該部分，但它還有一個額外的責任：它還必須讀取工作者產生的所有元組。 當計畫的平行部分僅產生少量元組時，領導者通常會非常像一個額外的工作者，從而加快查詢執行速度。 相反地，當計畫的平行部分產生大量元組時，領導者可能幾乎完全忙於讀取工作者產生的元組，並執行 Gather 節點或 Gather Merge 節點層級以上的計畫節點所需的任何進一步處理步驟。 在這種情況下，領導者將很少做執行計畫的平行部分的工作。

當計畫的平行部分頂端的節點是 Gather Merge 而不是 Gather 時，表示執行計畫的平行部分的每個程序都以排序的順序產生元組，並且領導者正在執行保留順序的合併。 相比之下，Gather 以任何方便的順序從工作者讀取元組，破壞可能存在的任何排序順序。