https://www.postgresql.org/docs/9.6/static/using-explain.html
Existing... 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 inheritance example]. [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 to start. David J.