Re: [PERFORM] COUNT(*) again (was Re: Index/Function - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: [PERFORM] COUNT(*) again (was Re: Index/Function
Date
Msg-id 1065301140.2746.37.camel@fuji.krosing.net
Whole thread Raw
In response to COUNT(*) again (was Re: Index/Function organized table layout)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PERFORM] COUNT(*) again (was Re: Index/Function organized table layout)
List pgsql-hackers
Tom Lane kirjutas L, 04.10.2003 kell 19:07:
> 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.

Please read further in my email ;)

The point I was trying to make was that faster count(*)'s is just a side
effect. If we could (conditionally) keep visibility info in indexes,
then this would also solve the problem fo much more tricky question of
index-structured tables.

Count(*) is *not* the only query that could benefit from not needing to
go to actual data table for visibilty info, The much more needed case
would be the "inveres time series" type of queries, which would
otherways trash cache pages badly.

----------------------------
Hannu


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: initdb
Next
From: Greg Stark
Date:
Subject: Re: max_connections/shared_buffers (was Re: Beta4 Tag'd and Bundled ...)