Re: EXPLAIN: Non-parallel ancestor plan nodes exclude parallel worker instrumentation

On Tue, Jun 23, 2020 at 2:57 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> I don't think this is an odd situation because in this case, child
> nodes like "Nested Loop" and "Parallel Seq Scan" has a value of
> 'loops' as 3. So, to get the correct stats at those nodes, you need
> to divide it by 3 whereas, at Gather node, the value of 'loops' is 1.
> If you want to verify this thing then try with a plan where loops
> should be 1 for child nodes as well, you should get the same value at
> both Gather and Parallel Seq Scan nodes.

Thanks for the response, but I still don't follow. I had assumed that
loops=3 was just from loops=1 for the parallel leader plus loops=1 for
each worker--is that not right? I don't see any other reason for
looping over the NL node itself in this plan. The Gather itself
doesn't do any real looping, right?

But even so, the documentation [1] states:

>In some query plans, it is possible for a subplan node to be executed more than once. For example, the inner index scan will be executed once per outer row in the above nested-loop plan. In such cases, the loops value reports the total number of executions of the node, and the actual time and rows values shown are averages per-execution. This is done to make the numbers comparable with the way that the cost estimates are shown. Multiply by the loops value to get the total time actually spent in the node.

So we should be seeing an average, not a sum, right?

[1]: https://www.postgresql.org/docs/current/using-explain.html#USING-EXPLAIN-ANALYZE