Horton

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

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Matthias van de Meent <boekewurm+postgres@gmail.com>
Cc: Peter Geoghegan <pg@bowt.ie>, Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Alexander Korotkov <aekorotkov@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>
Date: 2023-12-06T13:32:13Z
Lists: pgsql-hackers 
On Wed, Dec 6, 2023 at 8:27 AM Matthias van de Meent
<boekewurm+postgres@gmail.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

Commits

  1. Fix an oversight in refactoring in 06b10f80ba4.

  2. Make RangeTblEntry dump order consistent

  3. Improvements and fixes for e0b1ee17dc

  4. Remove BTScanOpaqueData.firstPage

  5. Optimize nbtree backward scan boundary cases.

  6. Skip checking of scan keys required for directional scan in B-tree