Re: Spped of max

From: nconway(at)klamath(dot)dyndns(dot)org (Neil Conway)
To: Doug Fields <dfields-pg-general(at)pexicom(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Spped of max
Date: 2002-05-15 01:58:55
Message-ID: 20020515015855.GA23543@klamath.dyndns.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, May 14, 2002 at 09:18:43PM -0400, Doug Fields wrote:
> >Since PostgreSQL allows user-defined aggregates, this is somewhat
> >difficult to optimize. No one has yet bothered to create special
> >cases for max(), min() and perhaps count(), although it could
> >probably be done.
>
> Perhaps you can suggest the fastest way of getting a table count, if it is
> not
>
> SELECT COUNT(*) FROM x WHERE ...;

Well, if you have a qualification (a WHERE ... clause), then count()
can be fast: it depends on the number of rows that match the
qualification. I can't see an obvious way to optimize count() on a
large subset of a table.

If you don't have a qualification (i.e. SELECT count(*) FROM x), there
are a couple ways to do it: use triggers to increment/decrement a
counter of the number of rows in the table, create a btree-indexed
SERIAL column and do an ORDER BY serial_column DESC LIMIT 1 on it (note
that this is fragile, your sequence could easily have holes), or if you
only need an approximation, you could use the pg_class attribute
"reltuples" for the OID of your table. My impression is that most
people choose the first method.

Cheers,

Neil

--
Neil Conway <neilconway(at)rogers(dot)com>
PGP Key ID: DB3C29FC

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Edmund Dengler 2002-05-15 02:34:29 Re: Spped of max
Previous Message Doug Fields 2002-05-15 01:18:43 Re: Spped of max