Re: Index only scan paving the way for "auto" clustered tables?

On Tue, Oct 11, 2011 at 4:00 PM, Florian Pflug <fgp(at)phlo(dot)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