Re: why does count take so long?
От | Greg Stark |
---|---|
Тема | Re: why does count take so long? |
Дата | |
Msg-id | 87smn75dwp.fsf@stark.dyndns.tv обсуждение исходный текст |
Ответ на | Re: why does count take so long? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: why does count take so long?
|
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: