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+TgmobuJpLirKvQwhOOp6bmSbRSga+Ctj=Z7wb9zAfFaz7rFg@mail.gmail.com
Whole thread Raw
In response to Index only scan paving the way for "auto" clustered tables?  (Royce Ausburn <royce.ml@inomial.com>)
Responses Re: Index only scan paving the way for "auto" clustered tables?  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers
On Tue, Oct 11, 2011 at 7:08 AM, Royce Ausburn <royce.ml@inomial.com> wrote:
> I wonder, could the recent work on index only scans pave the way for auto clustered tables?  Consider a wide, mostly
inserttable with some subset of columns that I'd like to cluster on.  I'm after locality of tuples that are very
frequentlyfetched together, but not keen on the downtime for a cluster, nor the maintenance that it requires.  Would it
bea stretch to have an index that branches on the subset of "cluster" columns, but still stores all the columns, making
ita covering index?  Given that we can already index concurrently, such an index would not require downtime, and would
beself maintaining.  From my understanding of the index-only scan implementation, I suspect that such an index would
effectivelygive locality, with some caveats… 

I guess we could do that, but I'm not convinced there would be much
benefit.  The only thing you'd be saving would be the cost of keeping
the tuples sorted by only the high-order columns rather than all of
them, and I doubt that's significant.

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


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: SET variable - Permission issues
Next
From: Joe Conway
Date:
Subject: Re: SET variable - Permission issues