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