Csaba Nagy wrote: > On Mon, 2007-10-08 at 09:40 +0100, Heikki Linnakangas wrote: >> This idea has been discussed to death many times before. Please search >> the archives. > > Somewhat related to the "visibility in index" thing: would it be > possible to have a kind of index-table ? We do have here some tables > which have 2-4 fields, and the combination of them forms the primary key > of the table. There are usually no other indexes on the table, and the > net result is that the PK index duplicates the heap. So it would be cool > if the index would be THE heap somehow...
The clustered index patch I worked on for 8.3, but didn't make it in, would have helped that use case a lot.
A column-store kind of mechanism would be nice. Some columns could be stored in index-like structures, while other would be in the heap. I haven't seen any practical proposal on how to do it though.
I think it more resembles the Oracle's IOT with overflow. I think my proposal, once implemented can be easily extended to incorporate IOT/Clustered indexes. One thing is for sure. Without storing Visibility info, Unique Secondary indexes(Indexes on IOT/Clustered indexed tables) is not possible, as it is not possible to re-locate the same entry in a b-tree, if we are storing the Primary key in place of tuple-id.
