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

Reply via email to