14.1.2 Explain Analyze
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. In the
above example, we spent a total of 0.220 milliseconds executing the index
scans on tenk2.
Additional topics to cover here (somewhere in this region)...
Parallel-executed queries executed in workers also result in an increase in
the number of loops. The total loop count will be equal to the number of
workers used, plus 1 if the leader contributed to retrieving rows. Note
that, presently, the leader's contributions are not detailed and can only
be imputed from the total for the node and the detail of the workers.
[other detail goes here - the whole block could be placed subsequent to the
[Possibly make a shorter form of this into a note...]
A nested-loop execution will often result in exactly 1 row being returned
per loop. In the parallel case, however, and especially when performing
parallel sequential scans with a highly-restrictive filter, it is possible
that few rows are returned. For instance, a parallel sequential scan on a
unique value will return a single row but might, including the leader, use
3 scans/loops to perform the work. In this case the average value per loop
would be 0.333+ - which is rounded down to zero since rows is expressed as
an integer. In any case when loops > 1 it can be necessary (though not
always sufficient) to examine the parent node to discover the total number
of records returned by the child node.
I'm sure I have some level of imprecision here but hopefully this is enough