Re: Indirect indexes
От | Claudio Freire |
---|---|
Тема | Re: Indirect indexes |
Дата | |
Msg-id | CAGTBQpYLe09v88FkU2UENhK+BqmHfLeYQsoB8LJV7VwOw8i0Fw@mail.gmail.com обсуждение исходный текст |
Ответ на | Indirect indexes (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: Indirect indexes
|
Список | pgsql-hackers |
On Tue, Oct 18, 2016 at 3:28 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > I propose we introduce the concept of "indirect indexes". I have a toy > implementation and before I go further with it, I'd like this assembly's > input on the general direction. > > Indirect indexes are similar to regular indexes, except that instead of > carrying a heap TID as payload, they carry the value of the table's > primary key. Because this is laid out on top of existing index support > code, values indexed by the PK can only be six bytes long (the length of > ItemPointerData); in other words, 281,474,976,710,656 rows are > supported, which should be sufficient for most use cases.[1] You don't need that limitation (and vacuum will be simpler) if you add the PK as another key, akin to: CREATE INDIRECT INDEX idx ON tab (a, b, c); turns into CREATE INDEX idx ON tab (a, b, c, pk); And is queried appropriately (using an index-only scan, extracting the PK from the index tuple, and then querying the PK index to get the tids). In fact, I believe that can work with all index ams supporting index-only scans.
В списке pgsql-hackers по дате отправления: