On Tue, Jun 23, 2020 at 2:57 AM Amit Kapila <amit.kapil...@gmail.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
