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

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [PERFORM] Slow count(*) again...
Дата
Msg-id 201102021603.p12G3bb09925@momjian.us
обсуждение исходный текст
Ответ на Re: [PERFORM] Slow count(*) again...  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
> > On 02/01/2011 05:47 PM, Bruce Momjian wrote:
> >> Tom Lane wrote:
> >>> At this point what we've got is 25% of the runtime in nodeAgg.c overhead,
> >>> and it's difficult to see how to get any real improvement without tackling
> >>> that.
> 
> >> Do we want a TODO about optimizing COUNT(*) to avoid aggregate
> >> processing overhead?
> 
> > Whether or not it's bad application design, it's ubiquitous, and we 
> > should make it work as best we can, IMNSHO. This often generates 
> > complaints about Postgres, and if we really plan for world domination 
> > this needs to be part of it.
> 
> I don't think that saving ~25% on COUNT(*) runtime will help that at all.
> The people who complain about it expect it to be instantaneous.
> 
> If this sort of hack were free, I'd be all for doing it anyway; but I'm
> concerned that adding tests to enable a fast path will slow down every
> other aggregate, or else duplicate a lot of code that we'll then have to
> maintain.

OK, thank you.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +


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

Предыдущее
От: "Kevin Grittner"
Дата:
Сообщение: Re: SSI patch version 14
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Where are we on SQl-MED?