Re: Strange count(*) implementation?

From: Tino Wildenhain <tino(at)wildenhain(dot)de>
To: Henk Ernst Blok <h(dot)e(dot)blok(at)utwente(dot)nl>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Strange count(*) implementation?
Date: 2004-10-26 11:28:21
Message-ID: 1098790101.21062.411.camel@sabrina.peacock.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ian Barwick 2004-10-26 11:30:49 Re: compatibilityissues from 7.1 to 7.4
Previous Message Sim Zacks 2004-10-26 11:02:40 Bug: 8.0 beta1 either view optimization or pgdump/pgrestore