PostgreSQL 并行查詢?nèi)绾喂ぷ?/h1>

當優(yōu)化器判斷對于某一個特定的查詢，并行查詢是最快的執(zhí)行策略時，優(yōu)化器將創(chuàng)建一個查詢計劃。該計劃包括一個 Gather或者Gather Merge節(jié)點。下面是一個簡單的例子：

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節(jié)點都只有一個子計劃，它是將被并行執(zhí)行的計劃的一部分。如果Gather或Gather Merge節(jié)點位于計劃樹的最頂層，那么整個查詢將并行執(zhí)行。如果它位于計劃樹的其他位置，那么只有查詢中在它之下的那一部分會并行執(zhí)行。在上面的例子中，查詢只訪問了一個表，因此除 Gather節(jié)點本身之外只有一個計劃節(jié)點。因為該計劃節(jié)點是Gather節(jié)點的孩子節(jié)點，所以它會并行執(zhí)行。

使用 EXPLAIN命令, 你能看到規(guī)劃器選擇的工作者數(shù)量。當查詢執(zhí)行期間到達Gather節(jié)點時，實現(xiàn)用戶會話的進程將會請求和規(guī)劃器選中的工作者數(shù)量一樣多的后臺工作者進程 。規(guī)劃器將考慮使用的后臺工作者的數(shù)量被限制為最多 max_parallel_workers_per_gather個。任何時候能夠存在的后臺工作者進程的總數(shù)由max_worker_processes和max_parallel_workers限制。因此，一個并行查詢可能會使用比規(guī)劃中少的工作者來運行，甚至有可能根本不使用工作者。最優(yōu)的計劃可能取決于可用的工作者的數(shù)量，因此這可能會導(dǎo)致不好的查詢性能。如果這種情況經(jīng)常發(fā)生，那么就應(yīng)當考慮一下提高 max_worker_processes和max_parallel_workers的值，這樣更多的工作者可以同時運行；或者降低max_parallel_workers_per_gather，這樣規(guī)劃器會要求少一些的工作者。

為一個給定并行查詢成功啟動的后臺工作者進程都將會執(zhí)行計劃的并行部分。這些工作者的領(lǐng)導(dǎo)者也將執(zhí)行該計劃，不過它還有一個額外的任務(wù)：它還必須讀取所有由工作者產(chǎn)生的元組。當整個計劃的并行部分只產(chǎn)生了少量元組時，領(lǐng)導(dǎo)者通常將表現(xiàn)為一個額外的加速查詢執(zhí)行的工作者。反過來，當計劃的并行部分產(chǎn)生大量的元組時，領(lǐng)導(dǎo)者將幾乎全用來讀取由工作者產(chǎn)生的元組并且執(zhí)行Gather或Gather Merge節(jié)點上層計劃節(jié)點所要求的任何進一步處理。在這些情況下，領(lǐng)導(dǎo)者所作的執(zhí)行并行部分的工作將會很少。

當計劃的并行部分的頂層節(jié)點是Gather Merge而不是Gather時，它表示每個執(zhí)行計劃并行部分的進程會產(chǎn)生有序的元組，并且領(lǐng)導(dǎo)者執(zhí)行一種保持順序的合并。相反，Gather會以任何方便的順序從工作者讀取元組，這會破壞可能已經(jīng)存在的排序順序。