有一些设置会导致查询规划器在任何情况下都不生成并行查询计划。为了生成任何并行查询计划，必须按以下指示配置以下设置。
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 消息的 fetch 计数不为零。请参阅关于 扩展查询协议 的讨论。由于 libpq 目前没有提供发送此类消息的方法，因此只有在使用不依赖于 libpq 的客户端时才会发生这种情况。如果经常发生这种情况，则可能需要在可能发生此情况的会话中将 max_parallel_workers_per_gather 设置为零，以避免生成在串行运行时可能次优的查询计划。
如果您在文档中看到任何不正确的内容，不符合您对特定功能的体验，或者需要进一步澄清，请使用 此表单 报告文档问题。