Re: Bug in nbtree optimization to skip > operator comparisons (or < comparisons in backwards scans) - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Bug in nbtree optimization to skip > operator comparisons (or < comparisons in backwards scans)
Date
Msg-id CAH2-Wznz=z3r3w15QTGB7rRj8ihec_jWWhroxTYGKU9-RKaFHw@mail.gmail.com
Whole thread Raw
In response to Re: Bug in nbtree optimization to skip > operator comparisons (or < comparisons in backwards scans)  (Alexander Korotkov <aekorotkov@gmail.com>)
Responses Re: Bug in nbtree optimization to skip > operator comparisons (or < comparisons in backwards scans)
List pgsql-hackers
On Tue, Dec 5, 2023 at 8:06 PM Alexander Korotkov <aekorotkov@gmail.com> wrote:
> Thank you for raising this issue.  Preprocessing of btree scan keys is
> normally removing the redundant scan keys.  However, redundant scan
> keys aren't removed when they have arguments of different types.
> Please give me a bit of time to figure out how to workaround this.

Couldn't you condition the use of the optimization on
_bt_preprocess_keys being able to use cross-type operators when it
checked for redundant or contradictory scan keys? The vast majority of
index scans will be able to do that.

As I said already, what you're doing here isn't all that different to
the way that we rely on required equality strategy scan keys being
used to build our initial insertion scan key, that determines where
the scan is initially positioned to within _bt_first. Inequalities
aren't all that different to equalities.

--
Peter Geoghegan



pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: [PoC] pg_upgrade: allow to upgrade publisher node
Next
From: Amit Kapila
Date:
Subject: Re: [PoC] pg_upgrade: allow to upgrade publisher node