Re: Plan output: actual execution time not considering loops?

Thomas Kellerer <spam_eater(at)gmx(dot)net> writes:
> Consider the following execution plan:
> ...
>     ->  Aggregate  (cost=26.87..26.87 rows=1 width=32) (actual time=0.012..0.012 rows=1 loops=700000)
>           ->  Bitmap Heap Scan on orders o2  (cost=3.45..26.85 rows=8 width=8) (actual time=0.004..0.008 rows=8 loops=700000)
>                 ->  Bitmap Index Scan on orders_customer_id_order_date_idx  (cost=0.00..3.45 rows=8 width=0) (actual time=0.003..0.003 rows=8 loops=700000)

> My expectation would have been that the "Aggregate" step shows the actual time as a product of the number of loops.

No, that looks fine to me. The rule of thumb for reading this is total
time spent in/below this node is "actual time" times "number of loops".

It seems a bit odd that the Agg node would account for a third of the
total execution time when it's only processing 8 rows on average ...
but maybe it's a really expensive aggregate.

Another thought is that the EXPLAIN ANALYZE instrumentation itself
can account for significant per-node-invocation overhead. If the
total execution time drops significantly when you add "timing off"
to the EXPLAIN options, then that's probably a factor in making
the Agg node look relatively expensive.

regards, tom lane