Re: Some problems regarding the self-join elimination code - Mailing list pgsql-hackers

From Andrei Lepikhov
Subject Re: Some problems regarding the self-join elimination code
Date
Msg-id 2d8756ba-a973-455b-b7ae-c55d85d96777@gmail.com
Whole thread Raw
In response to Re: Some problems regarding the self-join elimination code  (Richard Guo <guofenglinux@gmail.com>)
Responses Re: Some problems regarding the self-join elimination code
List pgsql-hackers
On 4/9/25 04:05, Richard Guo wrote:
> On Tue, Apr 8, 2025 at 11:12 PM Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
>> On Tue, 8 Apr 2025 at 12:31, Andrei Lepikhov <lepihov@gmail.com> wrote:
>> Perhaps the way to do it is to make ChangeVarNodesExtended() take a
>> callback function to be invoked for each node visited. The callback
>> (which would then be in the planner, with the other SJE code) would do
>> any special handling it needed (for RangeTblRef and RestrictInfo
>> nodes), and call ChangeVarNodes_walker() for any other types of node,
>> to get the default behaviour.
> 
> Yeah, this might be a better approach.  Perhaps we can borrow some
> ideas from replace_rte_variables.
It seems we are coming to the conclusion that join removal optimisation 
may do something out of ChangeVarNodes resposibility. Before further 
complicating of this function code I would like to know opinion of Tom, 
who initially proposed [1] to use this routine. May be better a) return 
to more specialised change_relid / sje_walker machinery or b) move 
ChangeVarNodes out of rewriteManip and make it multi-purpose routine, 
allowing to transform expression that may happen after a Var node change?

[1] https://www.postgresql.org/message-id/3622801.1715010885%40sss.pgh.pa.us

-- 
regards, Andrei Lepikhov



pgsql-hackers by date:

Previous
From: Luc Vlaming Hummel
Date:
Subject: Re: Assertion with aborted UPDATE in subtransaction
Next
From: Dmitry Dolgov
Date:
Subject: Re: Changing shared_buffers without restart