Re: Strange count(*) implementation? - Mailing list pgsql-general

From Tino Wildenhain
Subject Re: Strange count(*) implementation?
Date
Msg-id 1098790101.21062.411.camel@sabrina.peacock.de
Whole thread Raw
In response to Strange count(*) implementation?  (Henk Ernst Blok <h.e.blok@utwente.nl>)
Responses Re: Strange count(*) implementation?
List 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 by date:

Previous
From: Sim Zacks
Date:
Subject: Bug: 8.0 beta1 either view optimization or pgdump/pgrestore
Next
From: Ian Barwick
Date:
Subject: Re: compatibilityissues from 7.1 to 7.4