Message-ID: <7f6439c7-e5a7-4d0c-82c9-4087794cd9d0@gmail.com>
Date: Tue, 7 Apr 2026 10:22:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Clean up remove_rel_from_query() after self-join elimination
 commit
To: Richard Guo <guofenglinux@gmail.com>,
 Pg Hackers <pgsql-hackers@lists.postgresql.org>
References: 
 <CAMbWs48JC4OVqE=3gMB6se2WmRNNfMyFyYxm-09vgpm+Vwe8Hg@mail.gmail.com>
Content-Language: en-US
From: Andrei Lepikhov <lepihov@gmail.com>
In-Reply-To: 
 <CAMbWs48JC4OVqE=3gMB6se2WmRNNfMyFyYxm-09vgpm+Vwe8Hg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/7f6439c7-e5a7-4d0c-82c9-4087794cd9d0%40gmail.com>
Precedence: bulk

On 06/04/2026 10:11, Richard Guo wrote:
> Thoughts?
Thanks for your efforts!

The main goal of the SJE feature was to find common ground within the 
community - to come up with a solution that everyone could get behind on 
whether to allow optimisations that address redundant queries and reduce 
query tree complexity in early planning stages. So, some code roughness 
was ok.

I looked through your code, though maybe not as deeply as this part of 
the planner deserves. Overall, it looks good, and I didn’t spot any 
obvious problems, but I do have a few comments. We added some 
‘redundant’ checks with future optimisations in mind, so others can rely 
on these functions to remove tails from query structures or to error if 
something was left behind.

You explicitly write:

‘Each specific caller remains responsible for updating any remaining 
data structures required by its unique removal logic’

that differs from the initial idea. At the same time, by the end of SJE 
development, I wasn’t so sure we could invent a universal approach to 
guarantee the cleanup of the query tree - mostly because of the inherent 
volatility of the PlannerInfo structure and because we had not agreed to 
make the parse tree a read-only structure.

So, I’m fine with the changes in this patch.

-- 
regards, Andrei Lepikhov,
pgEdge