PostgreSQL 10.1 手冊_部分 II. SQL 語言_第 15章 并行查詢_15.1. 并行查詢如何工作

15.1. 并行查詢如何工作

當優化器判斷對于某一個特定的查詢，并行查詢是最快的執行政策時，優化器将建立一個查詢計劃。該計劃包括一個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

 以任何友善地順序從工作者讀取元組，進而破壞可能存在的任何排序順序。

本文轉自PostgreSQL中文社群，原文連結：