Re: Some problems regarding the self-join elimination code

From: Andrei Lepikhov <lepihov(at)gmail(dot)com>
To: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
Cc: Richard Guo <guofenglinux(at)gmail(dot)com>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Some problems regarding the self-join elimination code
Date: 2025-04-10 12:39:04
Message-ID: c74d27ed-6a39-4b4e-9b37-7910c3c71b82@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 4/10/25 13:36, Alexander Korotkov wrote:
> On Wed, Apr 9, 2025 at 10:39 AM Andrei Lepikhov <lepihov(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2025-04-10 12:46:35 Re: pgsql: Add function to get memory context stats for processes
Previous Message Peter Eisentraut 2025-04-10 12:37:36 Re: Consistently use macro HeapTupleIsValid to check the validity of tuples in tablecmds.c