Tom Lane <tgl@sss.pgh.pa.us> writes:
> Yeah, but I think he's complaining about the 10sec delta for the
> aggregate on top of the 71sec to read the 8 million rows. That
> seems high to me too. On a 10-mil-row test table, I get
...
> in other words 26sec to do the aggregate on top of 163sec to read the
> rows.
>
> Unless Joseph's machine has a way better IO-to-CPU ratio than my little
> development machine, there's something odd about his numbers.
Why is 10s (a 14% delta) for 8M records suspicious but 26s (16% delta) for 10M
not suspicious? These results seem fairly consistent actually.
I think what the original question was is "what work does this 10s represent".
I'm curious too. Is it really just 10 million times the cpu cycles necessary
to dispatch a call to the count() aggregate state function?
PS:
> regression=# explain analyze select count(*) from foo;
> QUERY PLAN
> ------------------------------------------------------------------------------------------------------------------
> Aggregate (cost=22.50..22.50 rows=1 width=0) (actual time=189865.81..189865.81 rows=1 loops=1)
> -> Seq Scan on foo (cost=0.00..20.00 rows=1000 width=0) (actual time=18.88..163833.61 rows=10240000 loops=1)
> Total runtime: 189865.91 msec
> (3 rows)
Hey, you haven't analyzed your table! :)
--
greg
