Re: GIN improvements part 1: additional information
| От | Alexander Korotkov |
|---|---|
| Тема | Re: GIN improvements part 1: additional information |
| Дата | |
| Msg-id | CAPpHfdvG+EvY26-bRAj=FzUUSm+O+9gc0g7PmM1fupxy2Ycv3g@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: GIN improvements part 1: additional information (Heikki Linnakangas <hlinnakangas@vmware.com>) |
| Ответы |
Re: GIN improvements part 1: additional information
Re: GIN improvements part 1: additional information |
| Список | pgsql-hackers |
Hi!
On Wed, Nov 20, 2013 at 9:02 PM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
On 06.11.2013 17:36, Alvaro Herrera wrote:No, they both refer to TIDs pointing to the heap.Just for my own illumination, can someone explain this bit?
+ If a posting list is too large to store in-line in a key entry, a posting tree
+ is created. A posting tree is a B-tree structure, where the ItemPointer is
+ used as the key. At the leaf-level, item pointers are stored compressed, in
+ "varbyte encoding".
I think the first ItemPointer mentioned (the key) refers to a TID
pointing to the index, and "item pointers stored compressed" refers to
the TIDs pointing to the heap (the data). Is that correct?Alexander's latest version filled in that explanation (haven't read it myself yet)I'm also interested in the "FIXME explain varbyte encoding" explanation
currently missing, if somebody can write it down ...
off-list
What's your plans about GIN now? I tried to rebase packed posting lists with head. But I found that you've changed interface of placeToPage function. That's conflicts with packed posting lists, because dataPlaceToPageLeaf needs not only offset number to describe place to insert item pointer. Do you like to commit rework of handling GIN incomplete splits before?
------
Alexander Korotkov.
В списке pgsql-hackers по дате отправления: