Re: Including Snapshot Info with Indexes
| От | Gokulakannan Somasundaram |
|---|---|
| Тема | Re: Including Snapshot Info with Indexes |
| Дата | |
| Msg-id | 9362e74e0710080306t3a0c32e4w6be8e94354ef5dc2@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Including Snapshot Info with Indexes ("Heikki Linnakangas" <heikki@enterprisedb.com>) |
| Список | pgsql-hackers |
On 10/8/07, Heikki Linnakangas <heikki@enterprisedb.com> wrote:
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.
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
В списке pgsql-hackers по дате отправления: