Re: proposal for smaller indexes on index-ordered tables

Jeffrey Baker wrote:
> The way I read it, the current btree index stores the index value and the
> TID of every tuple having that value.  When you have a table with three
> columns, you index one of them and you get an index which is practically as
> large as the table itself.
> 
> Supposing the table is generally or strictly ordered by the column to be
> indexed, it would be more compact if the index stored ranges of tuples.
> Instead of storing the TID of every tuple with that value, the index would
> store a first and last TID, between which all tuples have the value.

Search the archives for the Grouped Index Tuples, also known as 
Clustered Indexes patch I worked on in spring 2007. It did almost 
exactly that.

It didn't make it into 8.3 for various reasons: the patch was quite 
invasive, the design and performance characteristics were not 
well-understood by fellow hackers, and there was not that much interest 
in it back then.

I'm not working on it or planning to work on it for now, but if you're 
interested, the patch is still out there. It requires a lot of work, but 
the design is still viable. I'm certainly willing to help with it if 
someone wants to pick it up.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com