當最佳化器確定並行查詢是特定查詢的最快執行策略時，它將建立一個包含 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 以方便的任何順序從工作程序讀取元組，破壞了任何可能存在的排序順序。