有幾個設定會導致查詢規劃器在任何情況下都不會生成並行查詢計劃。為了能夠生成任何並行查詢計劃，必須按指示配置以下設定。
max_parallel_workers_per_gather 必須設定為大於零的值。這是更普遍原則的一個特例，即不應使用比透過 max_parallel_workers_per_gather 配置的更多工作程序。
此外，系統不能處於單使用者模式。在這種情況下，由於整個資料庫系統作為一個單一程序執行，因此沒有可用的後臺工作程序。
即使通常可以生成並行查詢計劃，但如果滿足以下任一條件，規劃器也不會為給定查詢生成它們：
查詢會寫入任何資料或鎖定任何資料庫行。如果查詢在頂層或 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 查詢，則該查詢永遠不會使用並行計劃。這是當前實現的一個限制，但移除此限制可能並不理想，因為它可能導致單個查詢使用非常多的程序。
即使為特定查詢生成了並行查詢計劃，在執行時也有幾種情況會導致無法並行執行該計劃。如果發生這種情況，領導者將完全由自己執行 Gather 節點下方的計劃部分，幾乎就像 Gather 節點不存在一樣。如果滿足以下任何條件，就會發生這種情況：
由於總後臺工作程序數不能超過 max_worker_processes 的限制，無法獲得後臺工作程序。
由於為並行查詢目的啟動的總後臺工作程序數不能超過 max_parallel_workers 的限制，無法獲得後臺工作程序。
客戶端傳送的 Execute 訊息的 fetch count 非零。請參見 擴充套件查詢協議 的討論。由於 libpq 目前不提供傳送此類訊息的方法，因此只有在使用不依賴 libpq 的客戶端時才會發生這種情況。如果這種情況頻繁發生，那麼在可能發生這種情況的會話中，將 max_parallel_workers_per_gather 設定為零可能是一個好主意，這樣可以避免生成在序列執行時可能不是最優的查詢計劃。
如果您在文件中發現任何不正確、與您對特定功能的體驗不符或需要進一步澄清的內容，請使用 此表格 報告文件問題。