Re: Index only scan paving the way for "auto" clustered tables? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Index only scan paving the way for "auto" clustered tables?
Date
Msg-id CA+TgmoagsBv91n96Zq6MRYf7psfjXT0SdpbWnOOxo=pf0L1uDA@mail.gmail.com
Whole thread Raw
In response to Re: Index only scan paving the way for "auto" clustered tables?  (Florian Pflug <fgp@phlo.org>)
List pgsql-hackers
On Tue, Oct 11, 2011 at 4:00 PM, Florian Pflug <fgp@phlo.org> wrote:
> On Oct11, 2011, at 21:27 , Robert Haas wrote:
>> Alternatively, we could try to graft the concept of a self-clustering
>> table on top of the existing heap implementation.  But I'm having
>> trouble seeing how that would work.  The TODO describes it as
>> something like "maintain CLUSTER ordering", but that's a gross
>> oversimplification, because we have no structure that would allow us
>> to sensibly do any such thing...  the current heap implementation is
>> just that: a pile of stuff.
>
> We could still be smarter about where we insert new rows in a clustered
> table, though.
>
> Upon INSERT and UPDATE, we'd need to lookup the leaf page where the new
> tuple will eventually go in the index we're supposed to maintain CLUSTER
> for. Then we'd check if any of the pages referenced there contains enough
> space, and if so place the new tuple there. If not it'd go at the end.

That's an interesting idea, but my guess is that the "if not" clause
would trigger frequently enough to make this not work very well.

Of course, we'd need to test it to know for sure....

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: COUNT(*) and index-only scans
Next
From: Tom Lane
Date:
Subject: Re: SET variable - Permission issues