Re: GiST VACUUM

Поиск
Список
Период
Сортировка
От Andrey Borodin
Тема Re: GiST VACUUM
Дата
Msg-id DABC2BB9-154A-47E2-B1D9-B58A4023E6D7@yandex-team.ru
обсуждение исходный текст
Ответ на Re: GiST VACUUM  (Heikki Linnakangas <hlinnaka@iki.fi>)
Ответы Re: GiST VACUUM
Список pgsql-hackers
Hi!

> 5 авг. 2018 г., в 16:18, Heikki Linnakangas <hlinnaka@iki.fi> написал(а):
>
> On 31/07/18 23:06, Andrey Borodin wrote:
>>> On a typical GiST index, what's the ratio of leaf vs. internal
>>> pages? Perhaps an array would indeed be better.
> >
>> Typical GiST has around 200 tuples per internal page. I've switched
>> to List since it's more efficient than bitmap.
>
> Hmm. A ListCell is 16 bytes, plus the AllocChunk header, 16 bytes. 32
> bytes per internal page in total, while a bitmap consumes one bit per page, leaf or internal. If I'm doing
> my math right, assuming the ratio of leaf pages vs internal pages is
> 1:200, a List actually consumes more memory than a bitmap; 256 bits per
> internal page, vs. 200 bits. An array, with 4 bytes per block number,
> would be the winner here.
We do not know size of this array beforehand. I can implement normal ArrayList though (with repallocing array) or
linkedlist of chunks. Or anything from data structures zoo. 
Or just stick with bitmap (my preferred way).
>
>> But I have to note that default growth strategy of Bitmap is not good: we will be repallocing byte by byte.
>
> True, that repallocing seems bad. You could force it to be pre-allocated
> by setting the last bit. Or add a function to explicitly enlarge the bitmap.
OK, I'll think of proper resize function (ensure capacity, to be precise).

Best regards, Andrey Borodin.



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

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Negotiating the SCRAM channel binding type
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: [report] memory leaks in COPY FROM on partitioned table