当优化器判断对于某一个特定的查询，并行查询是最快的执行策略时，优化器将创建一个查询计划。该计划包括一个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
以任何方便的顺序从工作者读取元组，从而破坏可能存在的任何排序顺序。