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