PostgreSQL/並行查詢
從 9.6 版本開始，PostgreSQL 支援並行處理查詢。在當今大多數伺服器中，存在大量的 CPU。併發使用這些 CPU 可以顯著縮短查詢的執行時間。因此，查詢最佳化器會嘗試建立計劃，以便為每個查詢執行多個程序。在執行時，這些程序會以協調的方式在共享緩衝區的不同部分並行工作。
並行執行由執行計劃中的“收集節點”發起。當在執行時到達這些節點時，實際執行的程序會請求計劃中指定的額外程序數量（“後臺工作程序”）。原始程序加上額外程序會並行執行計劃中的子節點。“收集節點”還有另外一項任務，即收集和累積其子程序的結果。
此功能並非在所有情況下都使用。這來自三個不同的影響：查詢型別、PostgreSQL 引數設定以及實際的實現。
- 如果查詢會導致執行計劃高度依賴 I/O，那麼並行化帶來的好處並不大，因為並行化是一種 RAM 訪問功能。相比之下，需要高 CPU 活動的查詢（例如：... where text like '%xyz%'；沒有相應的索引）將從並行化中獲益更多。因此，並行化更有可能被選擇用於第二種型別的查詢。
- PostgreSQL 的預設行為（在 9.6 版本中）是使用傳統行為，即只調用單個程序。如果想要使用並行化功能，則必須設定一些引數：
max_parallel_workers_per_gather定義了允許與每個“收集節點”並行執行的程序的最大數量。由於預設值為0，因此會導致使用傳統行為，除非更改此值。如上所述，每個與“收集節點”並行工作的程序都會在“後臺工作程序”中實現。每個例項中“後臺工作程序”的總數受max_worker_processes限制，預設值為8。因此，可能需要增加該值。此外，引數dynamic_shared_memory_type必須設定為除none以外的值。 - 9.6 版本的實際實現包含許多限制，這些限制源於必須確保此基本實現能夠在所有環境中穩定執行。在未來的版本中，其中一些限制可能會被消除。
- 它僅限於純只讀命令：不包括 UPDATE、DELETE，也不包括任何寫入命令的 CTE 部分。
- 如果涉及任何行的鎖。
- 如果事務隔離級別為
serializable。 - 如果查詢在另一個已並行化的查詢中執行。例如，如果由並行查詢呼叫的函式本身發出 SQL 查詢。