From: | Alena Rybakina <a(dot)rybakina(at)postgrespro(dot)ru> |
---|---|
To: | Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> |
Subject: | Re: pull-up subquery if JOIN-ON contains refs to upper-query |
Date: | 2025-02-11 15:59:55 |
Message-ID: | 300d7bb0-345c-4c0b-a0ef-4de573fcc94b@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10.02.2025 23:51, Ilia Evdokimov wrote:
>
> On 09.02.2025 18:14, Alena Rybakina wrote:
>> Hi! I found another example where the transformation worked
>> incorrectly and reconsidered the idea.
>>
>> As for conversion of exists_sublink_to_ANY, we need to get the
>> flattened implicit-AND list of clauses and pull out the chunks of the
>> WHERE clause that belong to the parent query,
>> since we are called halfway through the parent's
>> preprocess_expression() and earlier steps of preprocess_expression()
>> wouldn't get applied to the pulled-up stuff unless we do them here.
>> We also do some processing for vars depending on which side the var
>> is on - if it's in a subquery, we only need to lower its level
>> (varlevel) because subquery will be flatted, while
>> for other vars that belong to the parent query, we need to do
>> preparation to pull up the sub-select into top range table.
>>
>> For those expressions that we couldn't assign to either list, we
>> define newWhere and apply both cases.
>>
>
> When I run 'make -C contrib/ check', tests of postgres_fdw extension
> failed. I might be wrong, but you should be careful with LIMIT.
>
Thank you for the review, I'm working on it.
--
Regards,
Alena Rybakina
Postgres Professional
From | Date | Subject | |
---|---|---|---|
Next Message | Jelte Fennema-Nio | 2025-02-11 16:00:36 | Re: RFC: Allow EXPLAIN to Output Page Fault Information |
Previous Message | Isaac Morland | 2025-02-11 15:39:35 | Re: NOT ENFORCED constraint feature |