Re: Strange count(*) implementation?

Поиск
Список
Период
Сортировка
От Tino Wildenhain
Тема Re: Strange count(*) implementation?
Дата
Msg-id 1098790101.21062.411.camel@sabrina.peacock.de
обсуждение исходный текст
Ответ на Strange count(*) implementation?  (Henk Ernst Blok <h.e.blok@utwente.nl>)
Ответы Re: Strange count(*) implementation?  (Henk Ernst Blok <h.e.blok@utwente.nl>)
Список pgsql-general
hi,

On Tue, 2004-10-26 at 10:16, Henk Ernst Blok wrote:
> Hi Posgres users/developers,
>
> Can anyone explain why PosgreSQL (version 7.4.5 on Linux) does a full
> table scan to compute a count(*) on a base table after a vacuum analyze
> has been done with no following updates that might have outdated any
> statistics. Strangly the explain command does give the correct number of
> tuples instantaniously from the catalog, as one would expect. Still the
> optimizer thinks it needs a full table scan to do count.
>
...
> The consequence of this seemingly odd count implementation is a very
> very slow count.

How should the query planner know the vacuum was recent enough and there
were no modifications to the table since?

If you are interested in rough numbers you could read the system tables
for the last vacuum statistics. If you need fast count and can spend
some cycles on inserts, just make a buffer table with count results
after insert.

Unqualified count e.g. without a WHERE clause should not need to
be used a lot.

Regards
Tino


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

Предыдущее
От: Sim Zacks
Дата:
Сообщение: Bug: 8.0 beta1 either view optimization or pgdump/pgrestore
Следующее
От: Ian Barwick
Дата:
Сообщение: Re: compatibilityissues from 7.1 to 7.4