Re: Support specialized B-tree page searches - Mailing list pgsql-hackers

From Andrey Borodin
Subject Re: Support specialized B-tree page searches
Date
Msg-id 2F19CB19-5FDE-4B06-9CEF-6D8075B52B21@yandex-team.ru
Whole thread
In response to Support specialized B-tree page searches  (Andrey Borodin <x4mmm@yandex-team.ru>)
Responses Re: t/035_standby_logical_decoding.pl might fail on attempt to read wrong timeline
List pgsql-hackers

> On 5 Aug 2026, at 11:49, Andrey Borodin <x4mmm@yandex-team.ru> wrote:
>
> That is 35% less elapsed time, or 53% more throughput.  Standard
> pgbench -S did not show a measurable difference.

Нi hackers,

Here's the benchmarking followup.

I ran a broader set of benchmarks to look for both favorable and
unfavorable cases.  I compared master , the first patch with specialized
int4 binary search, and the full patch set.

These are median throughput changes from seven interleaved runs of one
million server-side index lookups:

                            specialized/master  full/specialized  full/master

  dense hits                       +8%                 +34%           +46%
  dense misses                    +12%                 +32%           +47%
  uniform random hits              +8%                 +25%           +35%
  clustered hits                   +9%                  +5%           +14%
  deduplicated duplicates          +3%                  +3%            +6%
  misses in large gaps             +7%                  +1%            +7%
  misses outside the range       +6..11%                -2%          +4..9%

Thus, specialization itself seems robust.  Interpolation provides a
large additional gain for approximately linear page contents, degrades
gracefully for clustered keys and duplicates, and costs about 2% over
specialized binary search for probes outside the indexed range.

Regular pgbench point lookups gained about 2.5-3%, where executor and
client overhead dilute the page-search improvement.  One case, duplicate
lookups with 16 clients, regressed by about 1.3%, I'm investigating this.

The insertion test also improved by about 6% with the first patch and
10% with the full patch set.  Interpolation is not used for insertion
bounds, however, and the second patch also refactors fixed-width tuple
extraction.  I will move that refactoring into the first patch and
repeat the focused insertion and adverse-case measurements. The gain
there is not from the interpolation.

I also tried the same approach for text and UUID.  Apart from about 1.3%
for densely packed UUID values, I found no convincing improvement, so I
do not plan to include those opclasses in the patch set.

Do these results make the opclass support procedure and the separate
interpolation callback look like a reasonable direction?  In
particular, is the distribution-dependent tradeoff acceptable when the
opclass retains the ability to fall back to binary search?


Best regards, Andrey Borodin.


pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: WAL compression setting after PostgreSQL LZ4 default change
Next
From: Nikhil Sontakke
Date:
Subject: Hot standby accepts connections (giving wrong results) before consistency after crash reset