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

From Neil Conway
Subject Re: Strange count(*) implementation?
Date
Msg-id 417E40AE.1080001@samurai.com
Whole thread Raw
In response to Re: Strange count(*) implementation?  (Henk Ernst Blok <h.e.blok@utwente.nl>)
List pgsql-general
Henk Ernst Blok wrote:
> I assume(d) the more expensive statistics (e.g., value distribution
> info) are updated only when outdated too much or on request (manual
> vacuum).

They are only updated on request -- i.e. when an ANALYZE is issued.

> So  if explain can get the most recent count, why
> not use it in the count as well if you know the statistics are still
> acurate?

Aside from the issue of stale statistics, there is another problem:
optimizer statistics are designed to be approximations. They are not
necessarily precise, even if ANALYZE has just been run (for example,
pg_class.reltuples is stored as a floating point number).

A practical problem is that aggregates like count() are implemented via
a general-purpose API; there is currently no provision for bypassing the
API in certain special case scenarios. See here for more info:

http://developer.postgresql.org/docs/postgres/functions-aggregate.html

-Neil

pgsql-general by date:

Previous
From: Henk Ernst Blok
Date:
Subject: Re: Strange count(*) implementation?
Next
From: Alvaro Herrera
Date:
Subject: Re: Strange count(*) implementation?