Re: pull-up subquery if JOIN-ON contains refs to upper-query

From: Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com>
To: Alena Rybakina <a(dot)rybakina(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: 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-10 20:51:29
Message-ID: 0adbf75a-2059-4bb7-b878-c33892dbc1f0@tantorlabs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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.

--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.

Attachment Content-Type Size
regression.diffs text/plain 5.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2025-02-10 20:52:46 Re: Track the amount of time waiting due to cost_delay
Previous Message Matheus Alcantara 2025-02-10 20:43:22 Re: explain analyze rows=%.0f