添加LIMIT或ROW_NUMBER后PostgreSQL停止并行化问题求助

问题根源 #

你遇到的情况核心原因是：LIMIT和带ORDER BY的ROW_NUMBER()会引入无法并行执行的计划节点，导致PostgreSQL无法将Parallel Append应用到整个UNION ALL查询上。

虽然LIMIT和ROW_NUMBER()函数本身不属于PostgreSQL文档定义的“并行不安全”函数，但它们对应的计划节点（Limit和WindowAgg）只能由leader进程处理，无法在并行worker中执行。当子查询包含这类节点时，整个子查询的计划会被标记为“不可并行”，外层的Parallel Append自然无法启用，只能串行执行每个子查询，最终导致性能大幅下降。

可行优化方案 #

1. 调整子查询结构，优先并行聚合再做限制 #

如果你的聚合操作使用的是并行安全函数（如sum、count、avg等内置函数），可以将子查询拆分为两层，让优化器优先完成并行聚合，再在单独步骤中做排序和限制：

SELECT * FROM (
  -- 内层：并行扫描+聚合单个表
  SELECT group_col, sum(metric) AS total
  FROM table_1
  GROUP BY group_col
) agg_result
ORDER BY total DESC
LIMIT 100

这种写法虽然仍会引入Limit节点，但能保证底层的表扫描和聚合是并行执行的，相比完全串行扫描仍能获得性能提升。

2. 使用FETCH FIRST ... WITH TIES简化限制逻辑 #

如果你的排序键是聚合值（比如按聚合结果降序取前100），可以用WITH TIES语法替代普通LIMIT，这种写法的计划生成逻辑更友好，可能减少优化器对并行计划的排斥：

SELECT group_col, sum(metric) AS total
FROM table_1
GROUP BY group_col
ORDER BY total DESC
FETCH FIRST 100 ROWS WITH TIES

注意：该语法会返回所有与第100条排序值相同的行，若业务允许近似前100条，这种方式效果更好。

3. 预计算物化视图 #

如果数据不是强实时要求，可以为每个表创建并行化的物化视图，预先存储分组聚合结果，后续直接从物化视图取数并做限制：

-- 创建物化视图（支持并行聚合）
CREATE MATERIALIZED VIEW mv_table_1 AS
SELECT group_col, sum(metric) AS total
FROM table_1
GROUP BY group_col
WITH DATA;

-- 查询物化视图的前100条
SELECT * FROM mv_table_1
ORDER BY total DESC
LIMIT 100;

刷新物化视图时可使用REFRESH MATERIALIZED VIEW CONCURRENTLY（需先创建唯一索引），支持并行刷新操作。

4. 应用层手动并行执行 #

如果上述方案都无法满足需求，可以在应用层将查询拆分为20个独立的子查询，每个子查询对应单个表的前100聚合结果，然后用多个并行数据库连接同时执行这些子查询，最后在应用层汇总结果。这种方式完全绕过PostgreSQL的并行计划限制，充分利用多核资源。

5. 调整并行参数引导优化器 #

尝试降低parallel_setup_cost和parallel_tuple_cost的值，让优化器更倾向于生成并行计划（建议在会话级别临时设置，避免影响全局查询）：

SET parallel_setup_cost = 100;
SET parallel_tuple_cost = 0.1;

注意：force_parallel_mode = on仅能强制优化器尝试生成并行计划，无法让本身不支持并行的节点（如Limit/WindowAgg）变为并行，因此对你的场景无效。

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