Horton

Re: Replace IN VALUES with ANY in WHERE clauses during optimization

Alena Rybakina <a.rybakina@postgrespro.ru>

View thread
From: Alena Rybakina <a.rybakina@postgrespro.ru>
To: Alexander Korotkov <aekorotkov@gmail.com>, Andrei Lepikhov <lepihov@gmail.com>
Cc: Ivan Kush <ivan.kush@tantorlabs.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Tom Lane <tgl@sss.pgh.pa.us>, Laurenz Albe <laurenz.albe@cybertec.at>
Date: 2025-03-01T11:39:11Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Stabilize regression test from c0962a113.

  2. Convert 'x IN (VALUES ...)' to 'x = ANY ...' then appropriate

  3. Extract make_SAOP_expr() function from match_orclause_to_indexcol()

Attachments

On 28.02.2025 14:48, Alena Rybakina wrote:
>
> Hi!
>
> On 21.02.2025 00:09, Alena Rybakina wrote:
>>
>> Hi!
>>
>> On 09.02.2025 18:38, Alexander Korotkov wrote:
>>>> Also, aren't we too restrictive while requiring is_simple_values_sequence()?
>>>> For instance, I believe cases like this (containing Var) could be transformed too.
>>>>
>>>> select * from t t1, lateral (select * from t t2 where t2.i in (values (t1.i), (1)));
>>
> I added it and attached a patch with diff file. To be honest, I didn't 
> find queries except for var with volatile functions where the 
> transform can't be applied.
>
I removed the function volatility check that I added in the previous 
version, since we already check it in is_simple_values_sequence.

> I'm not sure about only cases where var can refer to something outside 
> available_rels list but I couldn't come up with an example where 
> that's possible, what do you think?
>
Considering it again, I think we can't face problems like that because 
we don't work with join.

I attached a diff file as a difference with the 3rd version of the 
patch, when we did not consider the values with var for transformation.

-- 
Regards,
Alena Rybakina
Postgres Professional