On Fri, Dec 8, 2023 at 8:30 PM Alexander Korotkov <aekorot...@gmail.com> wrote: > On Wed, Dec 6, 2023 at 6:05 AM Alexander Korotkov <aekorot...@gmail.com> > wrote: > > On Wed, Dec 6, 2023 at 3:46 AM Peter Geoghegan <p...@bowt.ie> wrote: > > > On Tue, Dec 5, 2023 at 4:41 PM Peter Geoghegan <p...@bowt.ie> wrote: > > > > "In general, when inequality keys are present, the initial-positioning > > > > code only promises to position before the first possible match, not > > > > exactly at the first match, for a forward scan; or after the last > > > > match for a backward scan." > > > > > > > > My test case mostly just demonstrates how to reproduce the scenario > > > > described by this sentence. > > > > > > I just realized that my test case wasn't quite minimized correctly. It > > > depended on a custom function that was no longer created. > > > > > > Attached is a revised version that uses btint84cmp instead. > > > > 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. > > I dig into the problem. I think this assumption is wrong in my commit. > > "When the key is required for opposite direction scan, it must be > already satisfied by_bt_first() ..." > > In your example "foo = 90" is satisfied by_bt_first(), but "foo > > 99::int8" is not. I think this could be resolved by introducing a > separate flag exactly distinguishing scan keys used for _bt_first(). > I'm going to post the patch doing this.
The draft patch is attached. It requires polishing and proper commenting. But I hope the basic idea is clear. Do you think this is the way forward? ------ Regards, Alexander Korotkov
fix_btree_skip_scan_keys_optimization-v1.patch
Description: Binary data
