有時候看PostgreSQL的查詢執行計畫，可以看到一些parallel node在裡面，這就代表PostgreSQL成功將部分的query執行過程中的動作節點使用多個執行續來處理資料。

Parallel node介紹

Gather merge:將多個parallel worker的執行結果給整合起來。
Paralle seq. scan , parallel bitmap heap scan以及 parallel index scan等等的平行查詢節點，可以將該次掃描需要訪問的block分給多個程序來做掃描。
在做join的時候，inner table會被用非平行化的方式掃描，然後在情況曲可之下用平行掃描來掃outer table，但是hash join由於inner table需要被每一個在outer table計算和inner table相同的hash結果，所以有parallel hash join。
Parallel aggregate則是利用多個process將結果的一小部分進行聚合，然後再使用Gather Merge收集結果之後傳入final aggregate節點做最後統整。

Postgres決定是否使用平行化查詢的原因

由於處理程序的生成跟資料交換是需要成本的，因此開啟平行化功能並不一定比單執行續來得有效率。最明顯的考慮因素之一是要訪問table的資料量，這可以透過修改Postgres的參數來設定。如果掃描的table大小小於min_parallel_table_scan_size或者掃描的index大小小於min_parallel_index_scan_size，Postgres將不會開啟平行化的查詢。
另外Postgres系統上面能夠一次存在的parallel query process使用max_parallel_workers參數所指定，所以如果系統中有不少的parallel process正在跑，平行化查詢也可能不會啟用。另外max_worker_process則進一步規範系統上面允許同時間運行的worker process(其他用途例如create index的算在這裏面)

其他參數

max_parallel_workers_per_gather可以決定一個gather node下面的可平行化執行節點最多能使用幾個process來做平行化。
parallel_tuple_cost是Postgres優化器對於平行化query所計算的額外開銷，調整這個參數可以影響Postgres使用平行化查詢的決策。
force_parallel_mode設定打開會讓Postgres盡可能使用平行化查詢，可以做為實驗用途查看平行化查詢帶來的效能差異。