你已经做了最关键的基础配置——给函数标记PARALLEL SAFE、合理设置max_parallel_workers_per_gather，但9.6作为PostgreSQL引入并行查询的首个版本，有不少容易被忽略的限制，可能导致你的查询没按预期并行执行。下面是具体的排查点和解决思路：

1. 表大小未达并行扫描阈值 #

PostgreSQL不会为过小的表启动并行扫描——并行调度的开销可能比串行执行的收益还高。9.6中控制这个阈值的参数是min_parallel_table_scan_size，默认值为8MB（包含表的所有索引、TOAST数据）。

你可以先检查表的总大小：

SELECT pg_size_pretty(pg_total_relation_size('table'));

如果表大小低于阈值，可以临时调低参数测试：

SET min_parallel_table_scan_size = '1MB';

如果测试有效，想要永久生效可以修改postgresql.conf后重启服务。

2. 全局worker进程数不足 #

max_parallel_workers_per_gather控制单查询的并行worker上限，但还有全局参数max_worker_processes限制整个实例的worker总数。如果这个值设得太低（默认是8），即使单查询参数足够，也可能没有可用的worker进程。

检查当前设置：

SHOW max_worker_processes;

如果服务器有更多CPU核心，可以将其调高（比如16或32），修改postgresql.conf后重启生效。

3. 优化器认为并行不划算 #

PostgreSQL的优化器会对比串行和并行执行的成本，如果它判断并行收益有限，就不会选择并行计划。你可以通过EXPLAIN ANALYZE查看实际执行计划：

EXPLAIN ANALYZE SELECT expensive_func(a, b, c) FROM table;

如果输出中没有Gather或Parallel Seq Scan节点，说明优化器倾向于串行。此时可以调整两个成本参数引导优化器选择并行：

• parallel_setup_cost：启动并行worker的固定开销，默认1000，可调低至500
• parallel_tuple_cost：worker向leader传递每条数据的开销，默认0.1，可调低至0.05

临时调整命令：

SET parallel_setup_cost = 500;
SET parallel_tuple_cost = 0.05;

4. 函数内部隐含并行不安全操作 #

虽然你标记了函数为PARALLEL SAFE，但如果函数内部调用了并行不安全的操作（比如访问临时表、使用currval()/pg_backend_pid()这类依赖会话的函数），优化器可能会默默跳过并行计划。仔细检查你的PL/pgSQL函数逻辑，确保没有这类操作。

5. 9.6版本的固有局限性 #

作为并行查询的初代版本，PostgreSQL 9.6的并行支持有很多限制：比如对仅含单函数调用的简单查询，并行触发逻辑不够完善；对分区表的并行支持也有缺陷。如果可能的话，升级到PostgreSQL 12及以上版本会获得更成熟、灵活的并行查询能力，很多旧版本的限制都已被移除。

内容的提问来源于stack exchange，提问作者dan