Re: GiST VACUUM

Поиск
Список
Период
Сортировка
От Andrey Borodin
Тема Re: GiST VACUUM
Дата
Msg-id A51F64E3-850D-4249-814E-54967103A859@yandex-team.ru
обсуждение исходный текст
Ответ на Re: GiST VACUUM  (Andrey Borodin <x4mmm@yandex-team.ru>)
Ответы Re: GiST VACUUM  (Michael Paquier <michael@paquier.xyz>)
Re: GiST VACUUM  (Heikki Linnakangas <hlinnaka@iki.fi>)
Список pgsql-hackers
3 янв. 2019 г., в 23:47, Andrey Borodin <x4mmm@yandex-team.ru> написал(а):
>
>> * Bitmapset stores 32 bit signed integers, but BlockNumber is unsigned. So this will fail with an index larger than
2^31blocks. That's perhaps academical, I don't think anyone will try to create a 16 TB GiST index any time soon. But it
feelswrong to introduce an arbitrary limitation like that. 
> Looks like bitmapset is unsuitable for collecting block numbers due to the interface. Let's just create custom
containerfor this? 
> Or there is one other option: for each block number throw away sign bit and consider page potentially internal and
potentiallyempty leaf if (blkno & 0x7FFFFFF) is in bitmapset. 
> And then we will have to create at least one 17Tb GiST to check it actually works.

Heikki, how do you think, is implementing our own radix tree for this is viable solution?
I've written working implementation with 4-level statically typed tree. If we follow this route, probably, there must
betests for this data structure. 

Best regards, Andrey Borodin.

Вложения

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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: proposal: plpgsql pragma statement
Следующее
От: Greg Stark
Дата:
Сообщение: Re: Custom text type for title text