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

Поиск
Список
Период
Сортировка
От Matthias van de Meent
Тема btree: implement dynamic prefix truncation (was: Improving btree performance through specializing by key shape, take 2)
Дата
Msg-id CAEze2Wh-h20DmPSMXp4qHR0-ykh9=Z3ejX8MSsbikbOqaYe_OQ@mail.gmail.com
обсуждение исходный текст
Ответы Re: btree: implement dynamic prefix truncation (was: Improving btree performance through specializing by key shape, take 2)  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: btree: implement dynamic prefix truncation (was: Improving btree performance through specializing by key shape, take 2)  (Dilip Kumar <dilipbalaut@gmail.com>)
Список pgsql-hackers
Hi,

Currently, nbtree code compares each and every column of an index
tuple during the binary search on the index page. With large indexes
that have many duplicate prefix column values (e.g. an index on (bool,
bool, uuid) ) that means a lot of wasted time getting to the right
column.

The attached patch improves on that by doing per-page dynamic prefix
truncation: If we know that on both the right and left side there are
index tuples where the first two attributes are equal to the scan key,
we skip comparing those attributes at the current index tuple and
start with comparing attribute 3, saving two attribute compares. We
gain performance whenever comparing prefixing attributes is expensive
and when there are many tuples with a shared prefix - in unique
indexes this doesn't gain much, but we also don't lose much in this
case.

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].

Kind regards,

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

PS. Best served with the downlink right separator/HIKEY optimization
(separate patch to be submitted soon), and specialization over at [0].

[0] https://www.postgresql.org/message-id/CAEze2WiqOONRQTUT1p_ZV19nyMA69UU2s0e2dp+jSBM=j8snuw@mail.gmail.com

Вложения

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

Предыдущее
От: "Euler Taveira"
Дата:
Сообщение: Re: Allowing TRUNCATE of FK target when session_replication_role=replica
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Question about non-blocking mode in libpq