有一些設定可能會導致查詢規劃器在任何情況下都不會產生平行查詢計畫。 為了產生任何平行查詢計畫，必須按照指示配置以下設定。
max_parallel_workers_per_gather 必須設定為大於零的值。 這是更一般原則的一個特例，即使用的 Worker 數量不應超過透過 max_parallel_workers_per_gather 設定的數量。
此外，系統不得在單一使用者模式下執行。 由於整個資料庫系統在此情況下作為單一程序執行，因此沒有可用的背景 Worker。
即使通常可以產生平行查詢計畫，如果以下任何一項為真，規劃器也不會為給定的查詢產生平行查詢計畫
查詢會寫入任何資料或鎖定任何資料庫列。 如果查詢在最上層或在 CTE 內包含資料修改操作，則不會為該查詢產生平行計畫。 作為例外，以下指令會建立新資料表並填入資料，可以使用平行計畫來執行查詢中底層的 SELECT 部分
CREATE TABLE ... AS
SELECT INTO
CREATE MATERIALIZED VIEW
REFRESH MATERIALIZED VIEW
查詢可能會在執行期間暫停。 在系統認為可能會發生部分或增量執行的任何情況下，都不會產生平行計畫。 例如，使用 DECLARE CURSOR 建立的游標永遠不會使用平行計畫。 同樣地，FOR x IN query LOOP .. END LOOP 形式的 PL/pgSQL 迴圈永遠不會使用平行計畫，因為平行查詢系統無法驗證迴圈中的程式碼在平行查詢作用中時是否可以安全執行。
查詢使用任何標記為 PARALLEL UNSAFE 的函式。 大多數系統定義的函式都是 PARALLEL SAFE，但使用者定義的函式預設會標記為 PARALLEL UNSAFE。 請參閱關於 第 15.4 節的討論。
查詢正在已經是平行的另一個查詢中執行。 例如，如果平行查詢呼叫的函式本身發出 SQL 查詢，則該查詢永遠不會使用平行計畫。 這是目前實作的限制，但可能不希望移除此限制，因為這可能會導致單一查詢使用非常大量的程序。
即使為特定查詢產生了平行查詢計畫，在執行時也可能無法平行執行該計畫。 如果發生這種情況，Leader 將完全自行執行 Gather 節點下方的計畫部分，幾乎就像沒有 Gather 節點一樣。 如果滿足以下任何條件，就會發生這種情況
由於背景 Worker 的總數不能超過 max_worker_processes 的限制，因此無法取得任何背景 Worker。
由於為平行查詢啟動的背景 Worker 總數不能超過 max_parallel_workers 的限制，因此無法取得任何背景 Worker。
用戶端傳送包含非零提取計數的 Execute 訊息。 請參閱 延伸查詢協定的討論。 由於 libpq 目前沒有提供傳送此類訊息的方法，因此只有在使用不依賴 libpq 的用戶端時才會發生這種情況。 如果這經常發生，最好在可能發生的工作階段中將 max_parallel_workers_per_gather 設定為零，以避免產生在循序執行時可能次佳的查詢計畫。
如果您在文件中發現任何不正確、與您特定功能的經驗不符或需要進一步澄清的內容，請使用此表單回報文件問題。