PostgreSQL 12.5并行工作者数量不同时行数估算异常问题咨询

问题现象 #

执行1c.sql查询时，不同并行工作者数下的Seq Scan行数表现出异常比例：

• 并行工作者数=1时，估算行数与实际行数完全一致：

{
  "Node Type": "Seq Scan",
  "Parent Relationship": "Outer",
  "Parallel Aware": false,
  "Relation Name": "movie_info_idx",
  "Alias": "mi_idx",
  "Startup Cost": 0.00,
  "Total Cost": 21735.35,
  "Plan Rows": 1380035,
  "Plan Width": 50,
  "Actual Startup Time": 0.012,
  "Actual Total Time": 117.952,
  "Actual Rows": 1380035,
  "Actual Loops": 1
}

• 并行工作者数=3时，估算行数与实际行数满足plan_rows×4=actual_rows×5的比例关系：

{
  "Node Type": "Seq Scan",
  "Parent Relationship": "Outer",
  "Parallel Aware": true,
  "Relation Name": "movie_info_idx",
  "Alias": "mi_idx",
  "Startup Cost": 0.00,
  "Total Cost": 13685.15,
  "Plan Rows": 575015,
  "Plan Width": 8,
  "Actual Startup Time": 0.016,
  "Actual Total Time": 45.693,
  "Actual Rows": 460012,
  "Actual Loops": 3
}

原因分析 #

这个差异源于PostgreSQL 12.5中并行计划的估算逻辑：

1. 最优并行数的浮点计算：优化器生成并行计划时，会根据表的总大小、parallel_setup_cost（启动并行工作者的固定成本）、parallel_tuple_cost（工作者向leader传递单条数据的成本）等参数，计算出一个理论最优的并行工作者数量——这个值是浮点数，而非整数。
2. 估算行数的计算逻辑：对于并行Seq Scan，每个工作者的估算行数（Plan Rows）是表总行数除以这个最优并行数。
3. 实际执行的整数并行限制：当你手动设置max_parallel_workers_per_gather=3时，实际执行只能使用3个整数工作者，表数据会被平均分配给这3个工作者，因此每个工作者实际处理的行数是表总行数除以3。

结合你的案例具体推导：

• 表总行数为1380035，优化器计算出的最优并行数为2.4，因此估算行数为 1380035 / 2.4 ≈ 575015。
• 实际用3个工作者，每个工作者处理行数为 1380035 / 3 ≈ 460012。
• 两者比例为 3 / 2.4 = 5/4，因此满足 plan_rows×4=actual_rows×5。

这种估算与实际的差异是优化器为了计算全局最优成本而产生的正常逻辑——它会基于理论最优并行数做估算，即使实际只能使用整数个工作者。

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