Postgres EXPLAIN ANALYZE中Actual Loops指标计算规则咨询

你遇到的计算矛盾，核心原因是Actual Loops对应两类完全不同的节点执行模式，是否需要乘系数可以直接按执行模式判断：

需要乘以Actual Loops的场景：单线程串行重复执行 #

这类就是官方文档描述的典型场景，最常见的是嵌套循环连接（Nested Loop Join）的内侧扫描节点：外层执行流每输出一行，就会触发一次内侧节点的执行，所有执行过程都在同一个线程内串行完成。
该场景下的指标规则：

• Actual Total Time为单次执行的平均耗时，节点累计消耗的执行时间为显示值乘以Actual Loops
• Actual Rows为单次执行返回的平均行数，节点累计返回的总行数为显示值乘以Actual Loops

举个常规例子：嵌套循环外侧共输出1000行，内侧索引扫描的Actual Loops=1000，单次执行耗时0.001ms、返回1行，那么该索引扫描的总耗时为1ms，累计返回1000行，和官方文档给出的计算逻辑完全一致。

禁止乘以Actual Loops的场景：并行查询多worker并发执行 #

你给出的示例就属于这类场景：执行计划中出现Workers Planned、Workers Launched字段时，说明查询启用了多worker并行执行。
这类场景下的Actual Loops值，代表实际参与该节点执行的进程总数（通常为启动的worker数量+1个协调的leader进程，比如你的示例中启动了2个worker，加上leader共3个进程，对应所有并行分支节点的Actual Loops=3）。所有进程是同时并行运行的，不存在串行重复调用节点的情况。
该场景下的指标本身已经是聚合后的总值，不需要乘以loops：

• Actual Total Time是墙钟时间统计值，即从第一个进程开始执行该节点，到最后一个进程执行完该节点的总时间跨度，就是节点真实的执行耗时
• Actual Rows是所有进程在该节点返回的行数总和，就是节点真实的总输出行数

回到你给出的示例，Parallel Hash节点显示的782.085ms，是3个进程同时构建哈希表的总墙钟耗时，不是单进程执行782ms、串行执行3次。如果直接乘3，相当于把并行重叠的时间重复计算，得到的结果自然会大于根节点的总耗时，不符合实际执行逻辑。

快速校验技巧 #

如果拿不准是否需要乘系数，可以直接通过行数校验：

• 若节点属于并行执行分支，Actual Rows乘以loops后的结果会明显超出表总行数、上游节点输出的合理行数范围，说明显示值已经是聚合总值，不需要乘
• 若节点是嵌套循环内侧的串行执行节点，Actual Rows乘以loops后的结果会和连接节点的输出行数匹配，说明显示值是单次平均，需要乘

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