Re: Optimizing "boundary cases" during backward scan B-Tree index descents

2023-11-06 Thread Matthias van de Meent
On Sun, 15 Oct 2023 at 22:56, Peter Geoghegan wrote: > > On Mon, Sep 18, 2023 at 4:58 PM Peter Geoghegan wrote: > > Attached is v3, which is a straightforward rebase of v2. v3 is needed > > to get the patch to apply cleanly against HEAD - so no real changes > > here. > > Attached is v4. Just to

Re: Optimizing "boundary cases" during backward scan B-Tree index descents

2023-10-15 Thread Peter Geoghegan
On Mon, Sep 18, 2023 at 4:58 PM Peter Geoghegan wrote: > Attached is v3, which is a straightforward rebase of v2. v3 is needed > to get the patch to apply cleanly against HEAD - so no real changes > here. Attached is v4. Just to keep CFTester happy. -- Peter Geoghegan

Re: Optimizing "boundary cases" during backward scan B-Tree index descents

2023-09-18 Thread Peter Geoghegan
On Tue, Jun 20, 2023 at 5:12 PM Peter Geoghegan wrote: > I'm happy with the way that v2 came out, since the new structure makes > a lot more sense to me. Attached is v3, which is a straightforward rebase of v2. v3 is needed to get the patch to apply cleanly against HEAD - so no real changes

Re: Optimizing "boundary cases" during backward scan B-Tree index descents

2023-06-20 Thread Peter Geoghegan
On Mon, Jun 19, 2023 at 4:28 PM Peter Geoghegan wrote: > We still fall short when it comes to handling boundary cases optimally > during backwards scans. This is at least true for a subset of > backwards scans that request "goback=true" processing inside > _bt_first. Attached patch improves

Optimizing "boundary cases" during backward scan B-Tree index descents

2023-06-19 Thread Peter Geoghegan
An important goal of the work on nbtree that went into PostgreSQL 12 (and to a lesser extent the work that went into 13) was to make sure that index scans deal with "boundary cases" optimally. The simplest way of explaining what this means is through a practical worked example. Recap, worked