Re: Support specialized B-tree page searches

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: pgsql-hackers mailing list <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Support specialized B-tree page searches
Date: 2026-08-07 08:47:47
Message-ID: 2F19CB19-5FDE-4B06-9CEF-6D8075B52B21@yandex-team.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 5 Aug 2026, at 11:49, Andrey Borodin <x4mmm(at)yandex-team(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2026-08-07 08:55:03 Re: ri_Fast* crash w/ nullable UNIQUE constraint
Previous Message Andrey Borodin 2026-08-07 08:34:23 Re: WAL compression setting after PostgreSQL LZ4 default change