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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
