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