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

From: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
Subject: Re: Bug in nbtree optimization to skip > operator comparisons (or < comparisons in backwards scans)
Date: 2023-12-06 04:05:52
Message-ID: CAPpHfdtVwQioxmmUvWMHZVdRtGV=_uocMfM5Bqvt3R00Tm8n7w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi, Peter!

On Wed, Dec 6, 2023 at 3:46 AM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> On Tue, Dec 5, 2023 at 4:41 PM Peter Geoghegan <pg(at)bowt(dot)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.

------
Regards,
Alexander Korotkov

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2023-12-06 04:10:43 Re: [PoC] pg_upgrade: allow to upgrade publisher node
Previous Message Junwang Zhao 2023-12-06 03:18:35 Re: Make COPY format extendable: Extract COPY TO format implementations