From: | Royce Ausburn <royce(dot)ml(at)inomial(dot)com> |
---|---|
To: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Index only scan paving the way for "auto" clustered tables? |
Date: | 2011-10-11 11:08:27 |
Message-ID: | 13A47B0B-97DB-4BBE-B071-07C68DBA750F@inomial.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi all,
I wonder, could the recent work on index only scans pave the way for auto clustered tables? Consider a wide, mostly insert table with some subset of columns that I'd like to cluster on. I'm after locality of tuples that are very frequently fetched together, but not keen on the downtime for a cluster, nor the maintenance that it requires. Would it be a stretch to have an index that branches on the subset of "cluster" columns, but still stores all the columns, making it a covering index? Given that we can already index concurrently, such an index would not require downtime, and would be self maintaining. From my understanding of the index-only scan implementation, I suspect that such an index would effectively give locality, with some caveats…
I'd expect the overhead of inserting in to such a table would be high, perhaps prohibitive. Perhaps better ways have been discussed. Stupid idea?
--Royce
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2011-10-11 11:18:33 | Buildfarm git failures |
Previous Message | Robert Haas | 2011-10-11 11:00:49 | Re: table/index options | was: COUNT(*) and index-only scans |