Re: Some problems regarding the self-join elimination code

On Wed, Apr 9, 2025 at 10:39 AM Andrei Lepikhov <lepihov(at)gmail(dot)com> wrote:
> On 4/9/25 04:05, Richard Guo wrote:
> > On Tue, Apr 8, 2025 at 11:12 PM Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
> >> On Tue, 8 Apr 2025 at 12:31, Andrei Lepikhov <lepihov(at)gmail(dot)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?

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.

------
Regards,
Alexander Korotkov
Supabase