COUNT(*) again (was Re: Index/Function organized table layout) - Mailing list pgsql-hackers

From Tom Lane
Subject COUNT(*) again (was Re: Index/Function organized table layout)
Date
Msg-id 6102.1065283673@sss.pgh.pa.us
Whole thread Raw
In response to Re: Index/Function organized table layout (from Re:  (Hannu Krosing <hannu@tm.ee>)
Responses Re: [PERFORM] COUNT(*) again (was Re: Index/Function  (Hannu Krosing <hannu@tm.ee>)
List pgsql-hackers
Hannu Krosing <hannu@tm.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

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Using backslash in query
Next
From: Tom Lane
Date:
Subject: Re: Beta4 Tag'd and Bundled ...