COUNT(*) again (was Re: [HACKERS] Index/Function organized table layout)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hannu Krosing <hannu(at)tm(dot)ee>
Cc: Christopher Browne <cbbrowne(at)libertyrms(dot)info>, pgsql-performance(at)postgresql(dot)org, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: COUNT(*) again (was Re: [HACKERS] Index/Function organized table layout)
Date: 2003-10-04 16:07:53
Message-ID: 6102.1065283673@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

Hannu Krosing <hannu(at)tm(dot)ee> writes:
> Christopher Browne kirjutas R, 03.10.2003 kell 00:57:
>> A while back I outlined how this would have to be done, and for it to
>> be done efficiently, it would be anything BUT simple.

> Could this be made a TODO item, perhaps with your attack plan.

If I recall that discussion correctly, no one including Christopher
thought the attack plan was actually reasonable.

What this keeps coming down to is that an optimization that helps only
COUNT(*)-of-one-table-with-no-WHERE-clause would be too expensive in
development and maintenance effort to justify its existence.

At least if you insist on an exact, MVCC-correct answer. So far as I've
seen, the actual use cases for unqualified COUNT(*) could be handled
equally well by an approximate answer. What we should be doing rather
than wasting large amounts of time trying to devise exact solutions is
telling people to look at pg_class.reltuples for approximate answers.
We could also be looking at beefing up support for that approach ---
maybe provide some syntactic sugar for the lookup, maybe see if we can
update reltuples in more places than we do now, make sure that the
autovacuum daemon includes "keep reltuples accurate" as one of its
design goals, etc etc.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-10-04 16:16:45 Re: Beta4 Tag'd and Bundled ...
Previous Message Bruce Momjian 2003-10-04 15:56:40 Re: count(*) slow on large tables

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2003-10-04 16:49:33 Re: count(*) slow on large tables
Previous Message Bruce Momjian 2003-10-04 15:56:40 Re: count(*) slow on large tables