Re: Bug in nbtree optimization to skip > operator comparisons (or < comparisons in backwards scans)

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
Cc: Peter Geoghegan <pg(at)bowt(dot)ie>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Subject: Re: Bug in nbtree optimization to skip > operator comparisons (or < comparisons in backwards scans)
Date: 2023-12-06 13:32:13
Message-ID: CA+TgmoZhhgY1ftTyBJsm33tFMLe9cuoZuB7PT-ZgXa9gfNLtAg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 6, 2023 at 8:27 AM Matthias van de Meent
<boekewurm+postgres(at)gmail(dot)com> wrote:
> I feel that Peter refered to these two distinct optimizations:
>
> 1. When scanning an index in ascending order using scankey a > 1 (so,
> one that defines a start point of the scan), we don't need to check
> items for consistency with that scankey once we've found the first
> value that is consistent with the scankey, as all future values will
> also be consistent with the scankey (if we assume no concurrent page
> deletions).
>
> 2. When scanning an index in ascending order using scankey a < 10 (one
> that defines an endpoint of the scan), we can look ahead and check if
> the last item on the page is consistent. If so, then all other items
> on the page will also be consistent with that scankey.

Oh, interesting. Thanks.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2023-12-06 13:39:42 Re: logical decoding and replication of sequences, take 2
Previous Message Matthias van de Meent 2023-12-06 13:27:24 Re: Bug in nbtree optimization to skip > operator comparisons (or < comparisons in backwards scans)