public inbox for [email protected]
help / color / mirror / Atom feedFrom: Matthias van de Meent <[email protected]>
To: Peter Geoghegan <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Andrei Lepikhov <[email protected]>
Cc: Alexander Korotkov <[email protected]>
Cc: Alena Rybakina <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Finnerty, Jim <[email protected]>
Cc: Marcos Pegoraro <[email protected]>
Cc: Teodor Sigaev <[email protected]>
Cc: Ranier Vilela <[email protected]>
Cc: Tomas Vondra <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Subject: Re: POC, WIP: OR-clause support for indexes
Date: Tue, 28 Nov 2023 01:06:35 +0100
Message-ID: <CAEze2WiXm3VV-FLbBF2ViqHZarFgD2ufbS0VgwFuzjRLXRiemg@mail.gmail.com> (raw)
In-Reply-To: <CAH2-WznKiUwPtzLOVa7SQVSfurttZ+ULSRqhyseG_XbkYeyiag@mail.gmail.com>
References: <[email protected]>
<CA+Tgmob=ebuCHFSw327b55DJzE3JtOuZ5owxob+MgErb4me_Ag@mail.gmail.com>
<[email protected]>
<CA+TgmoaA+OXewcifo7ypr1szb_JP6m-qJp+K8iSenOPi9mtrbg@mail.gmail.com>
<CAH2-Wzkrg_nnh-xvnFZhNKEMJf0hZ0putQaqWhQrezEnb8b+XA@mail.gmail.com>
<CA+Tgmoa+ywixgrgV2x4QHJgLvre31wJDsx-dC1gXDmtJUgv=Ww@mail.gmail.com>
<CAPpHfdt58O5jzKMjkScNbGecM5JqfaMfdGLjs4rk5XisfjTNBw@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CAPpHfdu-_j6=E9CHjSGu0=SidfTqdtj7qk78dCdW-=4RFDHBDw@mail.gmail.com>
<[email protected]>
<CA+TgmoZCgP6FrBQEusn4yaWm02XU8OPeoEMk91q7PRBgwaAkFw@mail.gmail.com>
<CAH2-WznKiUwPtzLOVa7SQVSfurttZ+ULSRqhyseG_XbkYeyiag@mail.gmail.com>
On Mon, 27 Nov 2023, 23:16 Peter Geoghegan, <[email protected]> wrote:
> On Mon, Nov 27, 2023 at 1:04 PM Robert Haas <[email protected]> wrote:
> > The use of op_mergejoinable() seems pretty random to me. Why should we
> > care about that? If somebody writes a<1 or a<2 or a<3 or a<4, you can
> > transform that to a<any(array[1,2,3,4]) if you want. It might not be a
> > good idea, but I think it's a legal transformation.
>
> That kind of transformation is likely to be a very good idea, because
> nbtree's _bt_preprocess_array_keys() function knows how to perform
> preprocessing that makes the final index qual "a < 1". Obviously that
> could be far more efficient.
>
a < 4, you mean? The example mentioned ANY, not ALL
Further suppose you have a machine generated query "a<1 or a<2 or a<3
> or a<4 AND a = 2" -- same as before, except that I added "AND a = 2"
> to the end. Now _bt_preprocess_array_keys() will be able to do the
> aforementioned inequality preprocessing, just as before. But this time
> _bt_preprocess_keys() (a different function with a similar name) can
> see that the quals are contradictory. That makes the entire index scan
> end, before it ever really began.
>
With the given WHERE-clause I would hope it did *not* return before
scanning the index, given that any row with a < 3 is valid for that
constraint with current rules of operator precedence.
- Matthias
view thread (24+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: POC, WIP: OR-clause support for indexes
In-Reply-To: <CAEze2WiXm3VV-FLbBF2ViqHZarFgD2ufbS0VgwFuzjRLXRiemg@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox