Re: GIN improvements part 1: additional information

Поиск
Список
Период
Сортировка
От Alexander Korotkov
Тема Re: GIN improvements part 1: additional information
Дата
Msg-id CAPpHfdutJEC9+6vWX579afZKzdHKCT2wzDkAEom1XmiXEwF3pw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: GIN improvements part 1: additional information  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Ответы Re: GIN improvements part 1: additional information  (Peter Eisentraut <peter_e@gmx.net>)
Re: GIN improvements part 1: additional information  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Re: GIN improvements part 1: additional information  (Bruce Momjian <bruce@momjian.us>)
Re: GIN improvements part 1: additional information  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Список pgsql-hackers
On Sat, Jun 29, 2013 at 12:56 PM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
There's a few open questions:

1. How are we going to handle pg_upgrade? It would be nice to be able to read the old page format, or convert on-the-fly. OTOH, if it gets too complicated, might not be worth it. The indexes are much smaller with the patch, so anyone using GIN probably wants to rebuild them anyway, sooner or later. Still, I'd like to give it a shot.

2. The patch introduces a small fixed 32-entry index into the packed items. Is that an optimal number?

3. I'd like to see some performance testing of insertions, deletions, and vacuum. I suspect that maintaining the 32-entry index might be fairly expensive, as it's rewritten on every update to a leaf page.

It appears that maintaining 32-entry index is really expensive because it required re-decoding whole page. This issue is fixed in attached version of patch by introducing incremental updating of that index. Benchmarks will be posted later today.

------
With best regards,
Alexander Korotkov.  
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Minor inheritance/check bug: Inconsistent behavior
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE