Re: [PERFORM] Slow count(*) again...

Поиск
Список
Период
Сортировка
От Mladen Gogala
Тема Re: [PERFORM] Slow count(*) again...
Дата
Msg-id 4D489560.2040107@vmsinfo.com
обсуждение исходный текст
Ответ на Re: [PERFORM] Slow count(*) again...  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
On 2/1/2011 5:47 PM, Bruce Momjian wrote:
> Do we want a TODO about optimizing COUNT(*) to avoid aggregate
> processing overhead?
>

Definitely not.  In my opinion, and I've seen more than a few database 
designs, having count(*) is almost always an error.
If I am counting a large table like the one below,  waiting for 30 
seconds more is not going to make much of a difference.
To paraphrase Kenny Rogers, it will be time enough for counting when the 
application is done.

Timing is on.
news=> select count(*) from moreover_documents_y2011m01;  count
---------- 20350907
(1 row)

Time: 124142.437 ms
news=>

-- 

Mladen Gogala
Sr. Oracle DBA
1500 Broadway
New York, NY 10036
(212) 329-5251
http://www.vmsinfo.com
The Leader in Integrated Media Intelligence Solutions





В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [PERFORM] Slow count(*) again...
Следующее
От: Luis Ochoa
Дата:
Сообщение: A postgres parser related question