有几个设置可能导致查询计划器在任何情况下都不生成并行查询计划。为了生成任何并行查询计划，必须按以下指示配置设置。
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 的限制，因此无法获取任何后台工作人员。
客户端发送执行消息，其中包含非零提取计数。请参阅 扩展查询协议。由于 libpq 当前并没有提供任何发送此类消息的方式，因此只有在使用不依赖 libpq 的客户端时才会发生这种情况。如果这种情况经常发生，那么最好将 max_parallel_workers_per_gather 设置为零（在可能发生这种情况的会话中），以避免生成在串行运行时可能不理想的查询计划。