Re: why does count take so long?
От | Tom Lane |
---|---|
Тема | Re: why does count take so long? |
Дата | |
Msg-id | 2231.1063054916@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: why does count take so long? (Greg Stark <gsstark@mit.edu>) |
Ответы |
Re: why does count take so long?
|
Список | pgsql-general |
Greg Stark <gsstark@mit.edu> writes: > Tom Lane <tgl@sss.pgh.pa.us> writes: > Why is 10s (a 14% delta) for 8M records suspicious but 26s (16% delta) for 10M > not suspicious? These results seem fairly consistent actually. Duh --- must have gotten the decimal point off in my mental arithmetic. > 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? Well, it's 10 mil cycles of the aggregate plan node, which is going to involve rather more work than just the aggregate function call. But the last time I profiled COUNT(), it seemed that the pallocs/pfrees needed for the int8 counter were the largest single chunk of CPU time. Something I've wanted to do for awhile is to look at making int8 and float8 be pass-by-value datatypes on machines where Datum is naturally 8 bytes (ie, any 8-byte-pointer architecture). I doubt it would be a win to widen Datum on 32-bit machines, though; the distributed costs would swamp the advantage from making these datatypes more efficient. regards, tom lane
В списке pgsql-general по дате отправления: