Consider the following execution plan: Seq Scan on orders o1 (cost=0.00..18818840.86 rows=3500 width=16) (actual time=0.033..8625.104 rows=99906 loops=1) Filter: (amount = (SubPlan 1)) Rows Removed by Filter: 600094 Buffers: shared hit=7719778 SubPlan 1 -> Aggregate (cost=26.87..26.87 rows=1 width=32) (actual time=0.012..0.012 rows=1 loops=700000) Buffers: shared hit=7714631 -> 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) Recheck Cond: (customer_id = o1.customer_id) Heap Blocks: exact=5597311 Buffers: shared hit=7714631 -> 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) Index Cond: (customer_id = o1.customer_id) Buffers: shared hit=2117320 Planning time: 0.136 ms Execution time: 8628.724 ms
My expectation would have been that the "Aggregate" step shows the actual time as a product of the number of loops. The Bitmap Heap Scan takes 0.008ms for each execution, so shouldn't the "actual time" for the "Aggregate" step be 0.008ms * 700000 (= 5600ms)? The plan was generated using Postgres 10.4 (on Windows 10, but I think that is irrelevant) Thomas
