Tom Lane <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
