PostgreSQL 并行查询概述
2019獨角獸企業重金招聘Python工程師標準>>>
PostgreSQL從9.6版本開始加入并行查詢，并在PostgreSQL10和PostgreSQL11分別做了大量加強工作。下面從：
- 何時啟用并行查詢功能
- 并行查詢是如何工作的
- worker進程數量越多，查詢性能越高嗎
?三個方面簡單介紹下并行查詢的機制。
--------------------------------------------------------------------------------
何時啟用并行查詢功能
? ? 是否啟用并行查詢實際上有諸多因素決定。總的來說，有以下兩個方面：
- ? ?并行查詢開關等參數
????????在PostgreSQL系統中，并行查詢的開關是max_parallel_workers_per_gather，它所表示的是單個Gather節點所能開啟的最大worker進程數量。當設置為0時，是?禁用并行查詢，即沒有可提供的并行查詢的worker進程；該參數的默認值是2，即每個Gather節點最多可以有2個worker進程。需要注意的是，postgresql.conf文件中還有一個名為force_parallel_mode的參數（看參數名感覺像是并行查詢的開關參數），其實它表示是否強制開啟并行查詢，多用于測試為目的。如果設置為on，則無論何時都會進行并行查詢（實際上，這時并不見得會帶來查詢效率的提高，后面會有介紹），其默認值為off，這時系統會根據具體成本考慮是否啟用并行查詢。
????? ? 在并行查詢中，每個worker進程都會承擔部分的查詢工作。除了上面說的max_parallel_workers_per_gather參數外，系統還有一個參數max_parallel_workers，它決定系統所支持的最大的worker進程的數量，所以max_parallel_workers_per_gather的設定必須參考max_parallel_workers的值。當然，它們都得受限于max_worker_process（系統允許后臺開啟worker進程的最大數量）參數。
- ? ?并行查詢成本考慮
????? ? 當參數決定可以進行并行查詢后，實際上是否可以進行并行查詢，還得進行一些成本上的考慮。因為并行查詢除了能帶來并行查詢上的效率外，還會有一些成本的消耗，比如并行帶來的數據分片，進程間的通信以及并發控制所帶來的的系統的開銷等。當數據量足夠大時，并行查詢帶來的效率可以抵消這些成本考慮；但是數據量比較小時，并行查詢可能不會帶來效率的提升，反而會降低了原有的性能。而對于并行帶來的成本，系統需要進行計算其代價，然后決定是否啟用并行查詢。
????? ? 在配置文件中，有專門對并行查詢成本的設置：
parallel_tuple_cost = 0.1 # 后天進程傳遞tuple的代價parallel_setup_cost = 1000.0 # worker進程的啟動成本min_parallel_table_scan_size = 8MB # 并行查詢規定表的最小數據量min_parallel_index_scan_size = 512kB # 并行查詢規定的索引的最小數據量????? ? 系統就是依托上面的參數進行計算并行查詢的成本。這些參數基本上采用默認值就好，當然除非有特殊要求或特殊環境。
并行查詢是如何工作
? ? 以普通查詢為例，下面看一下簡單查詢的示例：
highgo=# explain analyze select * from test where n = 9999;QUERY PLAN ------------------------------------------------------------------------------------------------------------------------Gather (cost=1000.00..11822.39 rows=3984 width=36) (actual time=2.014..196.880 rows=1 loops=1)Workers Planned: 2Workers Launched: 2-> Parallel Seq Scan on test (cost=0.00..10423.99 rows=1660 width=36) (actual time=76.604..141.282 rows=0 loops=3)Filter: (n = 9999)Rows Removed by Filter: 333333Planning time: 0.044 msExecution time: 196.904 ms (8 行記錄)通過EXPLAIN可以查看并行查詢的執行計劃。當用戶輸入一個查詢語句時，查詢分析，查詢重寫以及查詢規劃都和原來一樣，只有到執行計劃時，才開始真正進入并行查詢環節。上面執行計劃中，Gather節點只是執行計劃的一個子節點，屬于執行計劃的一部分，當查詢執行走到Gather節點時，會話進程會申請一定數量的worker進程（根據配置參數，以及成本確定）來進行并行查詢過程。在這些worker進程中，有一個充當leader worker的角色，負責收集匯總各個worker進程查詢的結果。該leader worker進程也會根據查詢的數據量大小承擔部分的并行查詢部分。執行過程如下圖所示：
?
????? ? Leader worker進程和其他worker進程通過動態共享內存進行通信。其他worker進程（包括leader worker進程）把分擔查詢的結果存儲到共享內存中，然后由leader worker進程進行匯總整個查詢的結果。所以需要注意的是，由于并行查詢需要使用了動態共享內存，所以dynamic_shared_memory_type參數需要設置為none以外的值。
?
worker進程數量越多，查詢性能越高嗎
前面也提到，并不是所有的查詢都能適用于并行查詢。因為考慮到系統的開銷以及進程占用資源的情況，也并不是開啟的worker數量越多，查詢效率越高。下面以對同一個表做同樣的查詢，然后開啟不同的worker數量來測試一下。
- 開啟 1 個worker 進程
- 開啟 2 個worker 進程
- 開啟 4 個worker 進程
????????設置4個worker，但是實際上基于成本考慮只啟用了3個。????
highgo=# explain analyze select * from test where n = 4000000;QUERY PLAN ---------------------------------------------------------------------------------------------Gather (cost=1000.00..43285.39 rows=1 width=4) (actual time=190.967..191.017 rows=1 loops=1)Workers Planned: 3Workers Launched: 3-> Parallel Seq Scan on test (cost=0.00..42285.29 rows=1 width=4) (actual time=174.275..182.767 rows=0 loops=4)Filter: (n = 4000000)Rows Removed by Filter: 1250000Planning time: 0.119 msExecution time: 191.817 ms (8 rows)?
- 通過create table test(n int) with (parallel_workers = 4);強制啟動4個worker進程測試。
對比查詢結果：
| 1 worker 進程 | 2 worker 進程 | 3 worker 進程 | 4 worker 進程 |
| 302.026 ms | 219.005 ms | 191.817 ms | 185.391 ms |
可以看出，查詢效率并沒有隨worker數量線性增加；在啟用3個worker進程 和 4個worker進程進行并行查詢時，查詢效率基本一致了。所以并不是開啟的worker數量越多，查詢效率越高，這個也是系統有成本考慮在內。
?
?
轉載于:https://my.oschina.net/tianbing/blog/3029493
總結
以上是生活随笔為你收集整理的PostgreSQL 并行查询概述的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： testflight进行用户的beta测
- 下一篇： linux cmake编译源码,linu