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 c74d27ed-6a39-4b4e-9b37-7910c3c71b82@gmail.com
Whole thread Raw
In response to Re: Some problems regarding the self-join elimination code  (Alexander Korotkov <aekorotkov@gmail.com>)
Responses Re: Some problems regarding the self-join elimination code
List pgsql-hackers
On 4/10/25 13:36, Alexander Korotkov wrote:
> On Wed, Apr 9, 2025 at 10:39 AM Andrei Lepikhov <lepihov@gmail.com> wrote:
>> 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?
> 
> What about adding a callback to ChangeVarNodes_context that would
> called for each RestrictInfo after changing varnodes itself?  SJE
> could use a callback that replaces OpExpr with NullTest when needed.
I think it is doable, of course. Just looking forward a little, it may 
need more complication in the future (SJE definitely should be widened 
to partitioned tables) and it may be simpler to have two different 
routines for two different stages of planning.

-- 
regards, Andrei Lepikhov



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Consistently use macro HeapTupleIsValid to check the validity of tuples in tablecmds.c
Next
From: Tomas Vondra
Date:
Subject: Re: long-standing data loss bug in initial sync of logical replication