MIME-Version: 1.0
References: <567ED6CA.2040504@sigaev.ru> <cfdc7fef-cf0b-437b-89fa-62ffd6677f7d@postgrespro.ru>
 <59e67a40-95a8-4d74-ae4e-027ea0f59084@postgrespro.ru> <59b77a8a-29d6-4727-bf26-4a30a6a9719a@postgrespro.ru>
 <32d23d97-d07f-4d44-9933-ba3295fb3ed8@postgrespro.ru> <aec17a1a-9de0-4994-8a53-c6b4e64afb17@postgrespro.ru>
 <CACJufxGXhJ823cdAdp2Ho7qC-HZ3_-dtdj-myaAi_u9RQLn45g@mail.gmail.com>
 <CACJufxG=wB6qLbOAWaYEQHccN+qi=6-pw7zKVWZ53ZiDZNRTRA@mail.gmail.com>
 <CACJufxFrZS07oBHMk1_c8P3A84VZ3ysXiZV8NeU6gAnvu+HsVA@mail.gmail.com>
 <a155849d-7e74-4700-8c55-8a945d42935e@postgrespro.ru> <CACJufxFS-xcjaWq2Du2OyJUjRAyqCk12Q_zGOPxv61sgrdpw9w@mail.gmail.com>
 <7e11e27b-7ab9-4d59-af0a-a921861a9206@postgrespro.ru> <13ad923a-33df-4b44-9e00-c9323cd4c37d@postgrespro.ru>
 <CACJufxFSfSGZpmVt_98SRojdugW2s9H-qYm2sYr0A3o-xPea0g@mail.gmail.com>
 <e3338e82-a28d-4631-9eec-b9c0984b32d5@postgrespro.ru> <1cf6b382-6e27-4268-9f2a-54ada66eb2eb@postgrespro.ru>
 <CACJufxH-zju3VfosSRBu8d3xs99sGENn6+P3AETLuTiAPFY+0g@mail.gmail.com> <5f119769-ab11-4807-abcc-71d5dd914ea0@postgrespro.ru>
In-Reply-To: <5f119769-ab11-4807-abcc-71d5dd914ea0@postgrespro.ru>
From: jian he <jian.universality@gmail.com>
Date: Fri, 16 Feb 2024 20:54:16 +0800
Message-ID: <CACJufxFMFoosvbuFYDiFtpam4sKCSGJeh5jYiZSY8PHjCpEHYA@mail.gmail.com>
Subject: Re: POC, WIP: OR-clause support for indexes
To: Andrei Lepikhov <a.lepikhov@postgrespro.ru>
Cc: Alena Rybakina <a.rybakina@postgrespro.ru>, Alexander Korotkov <aekorotkov@gmail.com>, 
	Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org, 
	Peter Geoghegan <pg@bowt.ie>, "Finnerty, Jim" <jfinnert@amazon.com>, Marcos Pegoraro <marcos@f10.com.br>, 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/CACJufxFMFoosvbuFYDiFtpam4sKCSGJeh5jYiZSY8PHjCpEHYA%40mail.gmail.com>
Precedence: bulk

On Fri, Feb 16, 2024 at 1:32=E2=80=AFPM Andrei Lepikhov
<a.lepikhov@postgrespro.ru> wrote:
>
> On 16/2/2024 07:00, jian he wrote:
> > On Wed, Feb 14, 2024 at 11:21=E2=80=AFAM Andrei Lepikhov
> > <a.lepikhov@postgrespro.ru> wrote:
> > My OS: Ubuntu 22.04.3 LTS
> > I already set the max_parallel_workers_per_gather to 10.
> > So for all cases, it should use parallelism first?
> >
> > a better question would be:
> > how to make the number of OR less than 29 still faster when
> > enable_or_transformation is ON by only set parameters?
> In my test environment this example gives some subtle supremacy to ORs
> over ANY with only 3 ors and less.
> Please, provide next EXPLAIN ANALYZE results for the case you want to
> discuss here:
> 1. with enable_or_transformation enabled
> 2. with enable_or_transformation disabled
> 3. with enable_or_transformation disabled but with manual transformation
> OR -> ANY done, to check the overhead of this optimization.
>

you previously mentioned playing with parallel_tuple_cost and
parallel_setup_cost.
(https://www.postgresql.org/message-id/e3338e82-a28d-4631-9eec-b9c0984b32d5=
%40postgrespro.ru)

So I did by
`
SET parallel_setup_cost =3D 0;
SET parallel_tuple_cost =3D 0;
`

After setting these parameters, overall enable_or_transformation ON is
performance better.
sorry for the noise.
so now I didn't find any corner case where enable_or_transformation is
ON peforms worse than when it's OFF.

+typedef struct OrClauseGroupEntry
+{
+ OrClauseGroupKey key;
+
+ Node   *node;
+ List   *consts;
+ Oid scalar_type;
+ List   *exprs;
+} OrClauseGroupEntry;

I found that the field `scalar_type` was never used.