Re: btree: downlink right separator/HIKEY optimization

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
Cc: vignesh C <vignesh21(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, David Christensen <david(at)pgguru(dot)net>
Subject: Re: btree: downlink right separator/HIKEY optimization
Date: 2024-03-08 19:14:04
Message-ID: CAH2-WzkooESsOa8DKXkuYR-wuj2hcvcN5VrCCkNzSuXwM6WDFA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Feb 22, 2024 at 10:42 AM Matthias van de Meent
<boekewurm+postgres(at)gmail(dot)com> wrote:
> I forgot to address this in the previous patch, so here's v3 which
> fixes the issue warning.

What benchmarking have you done here?

Have you tried just reordering things in _bt_search() instead? If we
delay the check until after the binary search, then the result of the
binary search is usually proof enough that we cannot possibly need to
move right. That has the advantage of not requiring that we copy
anything to the stack.

Admittedly, it's harder to make the "binary search first" approach
work on the leaf level, under the current code structure. But maybe
that doesn't matter very much. And even if it does matter, maybe we
should just move the call to _bt_binsrch() that currently takes place
in _bt_first into _bt_search() itself -- so that _bt_binsrch() is
strictly under the control of _bt_search() (obviously not doable for
non-_bt_first callers, which need to call _bt_binsrch_insert instead).
This whole approach will have been made easier by the refactoring I
did late last year, in commit c9c0589fda.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Corey Huinker 2024-03-08 19:17:31 Re: Statistics Import and Export
Previous Message Daniel Gustafsson 2024-03-08 18:38:32 Re: pipe_read_line for reading arbitrary strings