Re: btree: implement dynamic prefix truncation (was: Improving btree performance through specializing by key shape, take 2)

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: btree: implement dynamic prefix truncation (was: Improving btree performance through specializing by key shape, take 2)
Дата
Msg-id CAFj8pRAi=tbWFYkpPuVL+b3B7Abd715Suvbg_=s+8-ABgm0Qvw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: btree: implement dynamic prefix truncation (was: Improving btree performance through specializing by key shape, take 2)  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Список pgsql-hackers


st 1. 11. 2023 v 11:32 odesílatel Matthias van de Meent <boekewurm+postgres@gmail.com> napsal:
On Wed, 1 Nov 2023 at 07:47, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>
> Hi
>
> út 31. 10. 2023 v 22:12 odesílatel Matthias van de Meent <boekewurm+postgres@gmail.com> napsal:
>> This patch was originally suggested at [0], but it was mentioned that
>> they could be pulled out into it's own thread. Earlier, the
>> performance gains were not clearly there for just this patch, but
>> after further benchmarking this patch stands on its own for
>> performance: it sees no obvious degradation of performance, while
>> gaining 0-5% across various normal indexes on the cc-complete sample
>> dataset, with the current worst-case index shape getting a 60%+
>> improved performance on INSERTs in the tests at [0].
>
>
> +1

Thanks for showing interest.

> This can be nice functionality. I had a customer with a very slow index scan - the main problem was a long common prefix like prg010203xxxx.

I'll have to note that this patch doesn't cover cases where e.g. text
attributes have large shared prefixes, but are still unique: the
dynamic prefix compression in this patch is only implemented at the
tuple attribute level; it doesn't implement type aware dynamic prefix
compression inside the attributes. So, a unique index on a column of
int32 formatted like '%0100i' would not materially benefit from this
patch.

While would certainly be possible to add some type-level prefix
truncation in the framework of this patch, adding that would require
significant code churn in btree compare operators, because we'd need
an additional return argument to contain a numerical "shared prefix",
and that is not something I was planning to implement in this patch.

Thanks for the explanation. 

Pavel


Kind regards,

Matthias van de Meent
Neon (https://neon.tech)

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

Предыдущее
От: Nikita Malakhov
Дата:
Сообщение: Re: remaining sql/json patches
Следующее
От: Aleksander Alekseev
Дата:
Сообщение: Re: Tab completion regression test failed on illumos