On 10/8/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote: > > 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. -- > Heikki Linnakangas > EnterpriseDB http://www.enterprisedb.com >
