Re: count(*) performance improvement ideas
От
Pavan Deolasee
Тема
Re: count(*) performance improvement ideas
Дата
Msg-id
2e78013d0803120959r515667ecl4edb3bd3afbfbdfe@mail.gmail.com
Ответ на
Re: count(*) performance improvement ideas (Mark Mielke)
Список
Дерево обсуждения
Re: count(*) performance improvement ideas "Stephen Denne" <Stephen.Denne@datamail.co.nz>
Re: count(*) performance improvement ideas Tom Lane <tgl@sss.pgh.pa.us>
Re: count(*) performance improvement ideas Magnus Hagander <magnus@hagander.net>
Re: count(*) performance improvement ideas Tom Lane <tgl@sss.pgh.pa.us>
Re: count(*) performance improvement ideas Bruce Momjian <bruce@momjian.us>
Re: count(*) performance improvement ideas Joe Conway <mail@joeconway.com>
Re: count(*) performance improvement ideas Tom Lane <tgl@sss.pgh.pa.us>
Re: count(*) performance improvement ideas "Stephen Denne" <Stephen.Denne@datamail.co.nz>
Re: count(*) performance improvement ideas Tom Lane <tgl@sss.pgh.pa.us>
Re: count(*) performance improvement ideas "Stephen Denne" <Stephen.Denne@datamail.co.nz>
Re: count(*) performance improvement ideas PFC <lists@peufeu.com>
Re: count(*) performance improvement ideas "Stephen Denne" <Stephen.Denne@datamail.co.nz>
Re: count(*) performance improvement ideas PFC <lists@peufeu.com>
Re: count(*) performance improvement ideas "Stephen Denne" <Stephen.Denne@datamail.co.nz>
Re: count(*) performance improvement ideas "Stephen Denne" <Stephen.Denne@datamail.co.nz>
Re: count(*) performance improvement ideas PFC <lists@peufeu.com>
On Wed, Mar 12, 2008 at 9:53 PM, Mark Mielke wrote: > > > > Fine - once per transaction instead of once per insert. Still, if there is > overhead to this (updating a secondary summary table), does it really make > sense to have it for every table? Most of my tables do not require count(*) > on the whole table (actually - none of them do). For the same reason as I > don't want oid, I don't think I would want "fast count" capabilities to > impact my regular queries. Again, I don't think count(*) on the whole table > is a particularly useful case. count(*) on particular subsets of the data > may be, but of the whole table? > ISTM that you are complaining because we never had an *fast* count(*) and adding that now comes at a cost. Had it been there from day one with the same overhead as we are talking about now, nobody would have complained :-) Anyways, your point is taken and it would be great if can make it configurable, if not table level then at least globally. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления
От: Bruce Momjian
Дата:
От: Alvaro Herrera
Дата: