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

From: Florian Pflug <fgp(at)phlo(dot)org>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Royce Ausburn <royce(dot)ml(at)inomial(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Index only scan paving the way for "auto" clustered tables?
Date: 2011-10-11 20:00:05
Message-ID: 2CA13047-BD41-40E6-95C5-7A833E73C923@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

best regards,
Florian Pflug

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2011-10-11 20:09:02 Re: SET variable - Permission issues
Previous Message Bruce Momjian 2011-10-11 19:57:56 Re: B-tree parent pointer and checkpoints