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 по дате отправления: