Message-ID: <e394ac5b-7ae2-4f64-a8ff-51fc934bba3e@postgrespro.ru>
Date: Tue, 5 Mar 2024 12:30:25 +0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: POC, WIP: OR-clause support for indexes
Content-Language: en-US
To: jian he <jian.universality@gmail.com>
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,
 Tomas Vondra <tomas.vondra@enterprisedb.com>,
 Peter Eisentraut <peter@eisentraut.org>, Ranier Vilela <ranier.vf@gmail.com>
References: <567ED6CA.2040504@sigaev.ru>
 <1cf6b382-6e27-4268-9f2a-54ada66eb2eb@postgrespro.ru>
 <CACJufxH-zju3VfosSRBu8d3xs99sGENn6+P3AETLuTiAPFY+0g@mail.gmail.com>
 <5f119769-ab11-4807-abcc-71d5dd914ea0@postgrespro.ru>
 <CACJufxFMFoosvbuFYDiFtpam4sKCSGJeh5jYiZSY8PHjCpEHYA@mail.gmail.com>
 <cf0d1615-b594-404d-9a23-3d8ffd9070ec@postgrespro.ru>
 <CAEudQAq4XTcwhw2OmfW1AJNqvMfbReEWjuzqv6YTz6ZjbpmL0g@mail.gmail.com>
 <21088129-7cd3-424a-bcce-6a3427ba3276@postgrespro.ru>
 <CAEudQArk002t_C9LGoeJWnw=iGKikt+gSa8Mh==muG00WS=qYA@mail.gmail.com>
 <CACJufxFhQn0awSEcZD7=FHvjx6OLt6PUtuoi0_10pWFVXUEDJw@mail.gmail.com>
 <ded629b2-7885-4be2-b5f5-9426ff47f72c@postgrespro.ru>
 <11ee9c04-281f-43c8-a0ff-d481c1e01c09@postgrespro.ru>
 <CACJufxGqLA32zTtaJRL2Cacp771k6PJnau7gsax0KRV434Qq7w@mail.gmail.com>
 <54009ba5-4aea-4344-a30d-e3558a59e2a9@postgrespro.ru>
 <380e5683-cdfd-4220-ab9b-7cccb9d3e480@postgrespro.ru>
 <CACJufxE6eG3ATnTfO9ubs7CjyfgjpCQrSt85oU33EZj00PdcbQ@mail.gmail.com>
From: Andrei Lepikhov <a.lepikhov@postgrespro.ru>
Organization: Postgres Professional
In-Reply-To: <CACJufxE6eG3ATnTfO9ubs7CjyfgjpCQrSt85oU33EZj00PdcbQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/e394ac5b-7ae2-4f64-a8ff-51fc934bba3e%40postgrespro.ru>
Precedence: bulk

On 4/3/2024 09:26, jian he wrote:
> On Thu, Feb 29, 2024 at 4:59 PM Andrei Lepikhov
>> Feel free to add, change or totally rewrite these changes.
On replacement of static ScalarArrayOpExpr dest with dynamic allocated one:
After discussion [1] I agree with that replacement.

Some style (and language) changes in comments I haven't applied because 
it looks debatable for me.

> I think it should be something like:
> + gettext_noop("Transform a sequence of OR expressions to an array
> expression."),
> + gettext_noop("The planner will replace expression like 'x=c1 OR x=c2 "
> + "to the expression 'x = ANY( ARRAY[c1,c2])''"
Fixed

> queryId may not be a good variable name here?
Not sure. QueryId is a concept, part of queryjumble technique and can be 
used by other tools. It just tells the developer what it is the same 
thing as Query Jumbling but for a separate expression.
At least you don't insist on removing of JumbleState return pointer that 
looks strange for a simple hash ...
> 
> comment `/* Compute query ID */`
> seems not correct, here we are just hashing the expression?
The same as above.
> +/*
> + * Dynahash match function to use in guc_hashtab
> the above comments seem not correct?
Yes, fixed.

> ` It applies to equality expressions only.` seems not correct?
> `select * from tenk1 where unique1 < 1 or unique1 < 2; ` can also do
> the transformation.
Yes, I forgot it.
> `similarity of variable sides.` seems not correct,
> should  it be 'sameness of the variable sides`?
The term 'equivalence' looks better *).

> in [2], we can get:
> SOME is a synonym for ANY. IN is equivalent to = ANY.
> 
> but still transforming OR to ANY is not intuitive.
> a normal user may not know what is "transforming OR to ANY".
> so maybe adding a simple example at
> <varlistentry id="guc-enable-or-transformation"
> xreflabel="enable_or_transformation">
> would be great. which, I did at previous thread.
Not sure. Examples in that section are unusual things. What's more, 
should a user who doesn't know what it means to change this setting? 
Let's wait for other opinions.

[1] https://www.postgresql.org/message-id/2157387.1709068790@sss.pgh.pa.us

-- 
regards,
Andrei Lepikhov
Postgres Professional