PostgreSQL 16存储过程中利用并行查询提升效率的方法

时间：2026-07-19 20:47

在PostgreSQL存储过程中，并行查询并不会自动生效，而是取决于查询计划，与函数封装无关。需要满足可分片且可合并的聚合条件，通过SETLOCAL命令调整并行相关参数，同时要避免使用volatile函数和锁定操作。只有当EXPLAIN输出中出现Gather节点时，才表示真正实现了并行查询。

关于存储过程并行查询，有一个常见的误解：很多人以为只要把 SQL 放进 CREATE OR REPLACE FUNCTION 里，就能自动享受并行加速。其实不然——并行与否，完全取决于执行语句本身的查询计划，跟函数封装没有直接关系。换句话说，函数只是个壳，里面跑什么计划，优化器说了算。

如何在PostgreSQL 16存储过程中利用并行查询提升效率？

PostgreSQL 的并行能力作用在「查询计划层级」，而不是「函数封装层级」。哪怕你在 plpgsql 函数里写了一个带 GROUP BY 的大查询，只要优化器没选中并行路径，它就还是老老实实串行跑。

怎么判断呢？最直接的办法是看 EXPLAIN ANALYZE 的输出。如果看到的是 GroupAggregate 节点，没有 Gather 或 Partial Aggregate，那就说明并行根本没启动，跟是不是在函数里无关。

常见原因有几个：

函数调用本身会引入额外开销（比如变量解析、控制流跳转），这会让优化器更倾向于保守的串行计划。
RETURN QUERY 或 FOR ... IN SELECT 中的查询，仍然按普通查询规则做代价估算，不会特殊照顾。
如果函数里用了 PERFORM 或中间赋值（比如 SELECT ... INTO），还可能触发 planner 的 early-exit 逻辑，跳过并行候选路径。

只有满足「可分片 + 可合并」条件的聚合，在函数内执行时才有机会走并行。关键看聚合函数和写法：

想要让函数里的查询走并行，需要手动干预参数，并且只对当前 session 或当前函数生效。推荐用 SET LOCAL：

设 worker 数：SET LOCAL max_parallel_workers_per_gather = 4;（别超 CPU 核心数）
压低门槛：SET LOCAL min_parallel_table_scan_size = 1MB;（小表测试可用，生产建议按实际大小设）
调低成本：SET LOCAL parallel_setup_cost = 2; 和 SET LOCAL parallel_tuple_cost = 0.01;
确保 work_mem 足够：SET LOCAL work_mem = '64MB';（总内存 ≈ (1 + workers) × work_mem）

注意：SET LOCAL 只影响当前函数调用内的 SQL，退出函数即恢复；但如果函数里开了事务块（BEGIN ... END），这些设置仍有效。

就算参数全调对了，某些写法也会让整个查询退回到串行：

在 SELECT 中调用 random()、now()、clock_timestamp() 等 volatile 函数。
用了 FOR UPDATE 或 SELECT ... INTO + 锁定行（即使没显式写 FOR UPDATE，某些隔离级别下也隐含）。
聚合字段上套了表达式，比如 string_agg(lower(name), ',') —— lower 是 stable，但若 name 列含 NULL，部分版本会绕过 partial path。
函数声明为 VOLATILE（默认行为），而内部查询又依赖 session 设置 —— 建议显式声明为 STABLE，避免 planner 过度保守。