Re: Improving btree performance through specializing by key shape, take 2

Поиск
Список
Период
Сортировка
От Matthias van de Meent
Тема Re: Improving btree performance through specializing by key shape, take 2
Дата
Msg-id CAEze2Wjc-1_hFd-MhRrA6Wczd1TUEq4keqc3aP3+u-px6hvwcA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Improving btree performance through specializing by key shape, take 2  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Ответы Re: Improving btree performance through specializing by key shape, take 2  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Список pgsql-hackers
On Sun, 5 Jun 2022 at 21:12, Matthias van de Meent
<boekewurm+postgres@gmail.com> wrote:
> While working on benchmarking the v2 patchset, I noticed no
> improvement on reindex, which I attributed to forgetting to also
> specialize comparetup_index_btree in tuplesorth.c. After adding the
> specialization there as well (attached in v3), reindex performance
> improved significantly too.

PFA version 4 of this patchset. Changes:
- Silence the compiler warnings,
- Extract itup_attiter code into its own header, so that we don't get
compiler warnings and pass the cfbot builds,
- Re-order patches to be in a more logical order,
- Updates to the dynamic prefix compression so that we don't always do
a _bt_compare on the pages' highkey. memcmp(parentpage_rightsep,
highkey) == 0 is often true, and allows us to skip the indirect
function calls in _bt_compare most of the time.

Based on local measurements, this patchset improves performance for
all key shapes, with 2% to 600+% increased throughput (2-86% faster
operations), depending on key shape. As can be seen in the attached
pgbench output, the performance results are based on beta1 (f00a4f02,
dated 2022-06-04) and thus not 100% current, but considering that no
significant changes have been made in the btree AM code since, I
believe these measurements are still quite valid.

I also didn't re-run the numbers for the main branch; but I compared
against the results of master in the last mail. This is because I run
the performance tests locally, and a 7-iteration pgbench run for
master requires 9 hours of downtime with this dataset, during which I
can't use the system so as to not interfere with the performance
tests. As such, I considered rerunning the benchmark for master to be
not worth the time/effort/cost with the little changes that were
committed.

Kind regards,

Matthias van de Meent.

Вложения

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

Предыдущее
От: Zhihong Yu
Дата:
Сообщение: Re: Removing unneeded self joins
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: TAP output format in pg_regress