Re: Faster count(*)?

Поиск
Список
Период
Сортировка
Искать
От
Richard Huxton
Тема
Re: Faster count(*)?
Дата
Msg-id
42FA0980.1060104@archonet.com
Ответ на
Faster count(*)? (Owen Jacobson)
Список
Дерево обсуждения
Faster count(*)? "Owen Jacobson" <ojacobson@osl.com>
Re: **SPAM** Faster count(*)? dracula007@atlas.cz
Re: **SPAM** Faster count(*)? Tom Lane <tgl@sss.pgh.pa.us>
Re: **SPAM** Faster count(*)? "Owen Jacobson" <ojacobson@osl.com>
Re: **SPAM** Faster count(*)? Michael Fuhr <mike@fuhr.org>
Re: **SPAM** Faster count(*)? Michael Fuhr <mike@fuhr.org>
Re: **SPAM** Faster count(*)? Andrew Sullivan <ajs@crankycanuck.ca>
Re: **SPAM** Faster count(*)? Keith Worthington <KeithW@NarrowPathInc.com>
Re: Faster count(*)? Richard Huxton <dev@archonet.com>
Owen Jacobson wrote:
> Salve.
> 
> I understand from various web searches and so on that PostgreSQL's MVCC
> mechanism makes it very hard to use indices or table metadata to optimise
> count(*).  Is there a better way to guess the "approximate size" of a table?

Plenty of good answers on how to estimate table-size, but it sounds like 
you just want to run your maintenance function "every so often".

1. Create a sequence "my_table_tracker_seq"
2. On insert, call nextval(my_table_tracker_seq)
3. If value modulo 1000 = 0, run the maintenance routine

That's about as fast as you can get, and might meet your needs. Of 
course you'll need to be more complex if you insert multiple rows at a time.

If you do a lot of deletion on the table and want to take that into 
account, have a second sequence you increment on deletion and subtract 
the one from the other.

Not always accurate enough, but it is quick.
--  Richard Huxton  Archonet Ltd

В списке pgsql-sql по дате отправления
От: Michael Fuhr
Дата:
Сообщение: Re: **SPAM** Faster count(*)?
От: Owen Jacobson
Дата:
Сообщение: Re: **SPAM** Faster count(*)?
FAQ