MIME-Version: 1.0
References: <567ED6CA.2040504@sigaev.ru> <b301dce1-09fd-72b1-834a-527ca428db5e@yandex.ru>
 <CAH2-WzmG-+vvN6YEh4J_j3-Q1Yn=HRrjDrz2HDhttPcLVqN0rw@mail.gmail.com>
 <bf504287-c3ac-e492-c6ea-31be60b2c92f@yandex.ru> <CAH2-WzkmLg0JPXkZ75b+ha_wJGoJk3QyZ6aUjA0Ba11rdPwdgw@mail.gmail.com>
 <fa5f57e1-4051-93d8-5f54-f1e2f4587cc2@yandex.ru> <4bac271d-1700-db24-74ac-8414f2baf9fd@postgrespro.ru>
 <CAH2-Wzkp1RYWC4Lsh==ALNeOR=gQEtCMVbcFRLa-faMQe6YRPA@mail.gmail.com>
 <CAH2-Wz=rJOP_1niMTSN_=pzKXUu5tAGRYMGj6uC6Xx=XzkgdPg@mail.gmail.com>
 <d3db5422-bef3-8009-0f4c-5fdaea849184@postgrespro.ru> <a2941c7a-df4f-c4f3-bca2-2fcc450980f7@eisentraut.org>
 <e562286f-4442-6ea7-19d1-896c349e96e0@postgrespro.ru> <d6e3fc3c-6f1c-2586-3fa2-ef793045047c@postgrespro.ru>
 <89fb769c-7d45-f0c5-a9b3-b706c9661c57@postgrespro.ru> <668892c1-fb11-3a79-ce5e-1c194b7b3263@postgrespro.ru>
 <CAPpHfduJtO0s9E=SHUTzrCD88BH0eik0UNog1_q3XBF2wLmH6g@mail.gmail.com>
 <CA+Tgmob=ebuCHFSw327b55DJzE3JtOuZ5owxob+MgErb4me_Ag@mail.gmail.com>
 <aca9dad7-27ef-4724-8a16-435a45640545@postgrespro.ru> <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>
In-Reply-To: <CA+Tgmoa+ywixgrgV2x4QHJgLvre31wJDsx-dC1gXDmtJUgv=Ww@mail.gmail.com>
From: Alexander Korotkov <aekorotkov@gmail.com>
Date: Mon, 30 Oct 2023 16:06:41 +0200
Message-ID: <CAPpHfdt58O5jzKMjkScNbGecM5JqfaMfdGLjs4rk5XisfjTNBw@mail.gmail.com>
Subject: Re: POC, WIP: OR-clause support for indexes
To: Robert Haas <robertmhaas@gmail.com>
Cc: Peter Geoghegan <pg@bowt.ie>, Alena Rybakina <a.rybakina@postgrespro.ru>, pgsql-hackers@postgresql.org, 
	"Finnerty, Jim" <jfinnert@amazon.com>, Marcos Pegoraro <marcos@f10.com.br>, 
	Andrey Lepikhov <a.lepikhov@postgrespro.ru>, teodor@sigaev.ru, 
	Ranier Vilela <ranier.vf@gmail.com>, Tomas Vondra <tomas.vondra@enterprisedb.com>, 
	Peter Eisentraut <peter@eisentraut.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAPpHfdt58O5jzKMjkScNbGecM5JqfaMfdGLjs4rk5XisfjTNBw%40mail.gmail.com>
Precedence: bulk

On Mon, Oct 30, 2023 at 3:40=E2=80=AFPM Robert Haas <robertmhaas@gmail.com>=
 wrote:
> On Thu, Oct 26, 2023 at 5:05=E2=80=AFPM Peter Geoghegan <pg@bowt.ie> wrot=
e:
> > On Thu, Oct 26, 2023 at 12:59=E2=80=AFPM Robert Haas <robertmhaas@gmail=
.com> wrote:
> > > Alexander's example seems to show that it's not that simple. If I'm
> > > reading his example correctly, with things like aid =3D 1, the
> > > transformation usually wins even if the number of things in the OR
> > > expression is large, but with things like aid + 1 * bid =3D 1, the
> > > transformation seems to lose at least with larger numbers of items. S=
o
> > > it's not JUST the number of OR elements but also what they contain,
> > > unless I'm misunderstanding his point.
> >
> > Alexander said "Generally, I don't see why ANY could be executed
> > slower than the equivalent OR clause". I understood that this was his
> > way of expressing the following idea:
> >
> > "In principle, there is no reason to expect execution of ANY() to be
> > slower than execution of an equivalent OR clause (except for
> > noise-level differences). While it might not actually look that way
> > for every single type of plan you can imagine right now, that doesn't
> > argue for making a cost-based decision. It actually argues for fixing
> > the underlying issue, which can't possibly be due to some kind of
> > fundamental advantage enjoyed by expression evaluation with ORs".
> >
> > This is also what I think of all this.
>
> I agree with that, with some caveats, mainly that the reverse is to
> some extent also true. Maybe not completely, because arguably the
> ANY() formulation should just be straight-up easier to deal with, but
> in principle, the two are equivalent and it shouldn't matter which
> representation we pick.
>
> But practically, it may, and we need to be sure that we don't put in
> place a translation that is theoretically a win but in practice leads
> to large regressions. Avoiding regressions here is more important than
> capturing all the possible gains. A patch that wins in some scenarios
> and does nothing in others can be committed; a patch that wins in even
> more scenarios but causes serious regressions in some cases probably
> can't.

+1
Sure, I've identified two cases where patch shows regression [1].  The
first one (quadratic complexity of expression processing) should be
already addressed by usage of hash.  The second one (planning
regression with Bitmap OR) is not yet addressed.

Links
1. https://www.postgresql.org/message-id/CAPpHfduJtO0s9E%3DSHUTzrCD88BH0eik=
0UNog1_q3XBF2wLmH6g%40mail.gmail.com

------
Regards,
Alexander Korotkov