Re: **SPAM** Faster count(*)?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: **SPAM** Faster count(*)?
Дата
Msg-id 21626.1123642154@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: **SPAM** Faster count(*)?  (dracula007@atlas.cz)
Ответы Re: **SPAM** Faster count(*)?  (Michael Fuhr <mike@fuhr.org>)
Re: **SPAM** Faster count(*)?  (Andrew Sullivan <ajs@crankycanuck.ca>)
Re: **SPAM** Faster count(*)?  ("Owen Jacobson" <ojacobson@osl.com>)
Re: **SPAM** Faster count(*)?  (Keith Worthington <KeithW@NarrowPathInc.com>)
Список pgsql-sql
dracula007@atlas.cz writes:
> I believe running count(*) means fulltable scan, and there's no way
> to do it without it. But what about some "intermediate" table, with
> the necessary counts?

There's a fairly complete discussion in the PG list archives of a
reasonably-efficient scheme for maintaining such counts via triggers.
It wasn't efficient enough that we were willing to impose the overhead
on every application ... but if you really NEED a fast count(*) you
could implement it.  I'd like to see someone actually do it and put
up working code on pgfoundry; AFAIK it's only a paper design so far.

If you only want a very-approximate count, the best bet is to rely on
the planner's estimates, eg

regression=# explain select * from tenk1;                        QUERY PLAN                          
-------------------------------------------------------------Seq Scan on tenk1  (cost=0.00..458.00 rows=10000
width=244)                                          ^^^^^
 

Current best practice is to run the explain and parse out the "rows"
figure using a perl (or axe-of-choice) regexp, though we could be
persuaded to supply a simpler API if there's enough demand for it.
        regards, tom lane


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

Предыдущее
От: dracula007@atlas.cz
Дата:
Сообщение: Re: **SPAM** Faster count(*)?
Следующее
От: Michael Fuhr
Дата:
Сообщение: Re: **SPAM** Faster count(*)?