The way I read it, the current btree index stores the index value and the TID of every tuple having that value. When
youhave a table with three columns, you index one of them and you get an index which is practically as large as the
tableitself.<br /><br />Supposing the table is generally or strictly ordered by the column to be indexed, it would be
morecompact if the index stored ranges of tuples. Instead of storing the TID of every tuple with that value, the index
wouldstore a first and last TID, between which all tuples have the value.<br /><br />Example: table with one million
rowsindexed on a column having one thousand distinct values. Table is in-order by the indexed column. The traditional
indexwould contain a million TIDs, whereas a range index would contain only two thousand. The range index would be 500
timessmaller, more likely to be cached, etc.<br /><br />Thoughts?<br /><br />-jwb<br />