Re: Removing unneeded self joins - Mailing list pgsql-hackers

From Andrei Lepikhov
Subject Re: Removing unneeded self joins
Date
Msg-id 6e17d257-68d7-44f0-a54b-0ea49bfd1dbd@gmail.com
Whole thread Raw
In response to Re: Removing unneeded self joins  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On 27/6/2025 02:26, Michael Paquier wrote:
> The point regarding the search join hook may stand, though.  Perhaps
> somebody should check if we're still OK with this change in the
> context of the self-join work.  I tend to think that we are and I
> agree that removing the joins when calling the hook can show benefits,
> but it may be surprising and users tend to be very noisy with plan
> stability, particularly if some of the FROM aliases get silenced by
> the backend without the module knowing about that.  At least there is
> the trick with SET enable_self_join_elimination available as a last
> resort method.
Parse tree transformation (pull-ups, flattenings) adds joins, constant 
clause evaluation or partition pruning may smash whole subtrees - the 
optimisation process is quite unstable from the query structure's point 
of view.
If I understand correctly, pg_hint_plan needs to differentiate 'never 
existed' relations and removed ones. In that sense, up to v.15, Postgres 
saved RelOptInfo after removing the join (see e9a20e4).

-- 
regards, Andrei Lepikhov



pgsql-hackers by date:

Previous
From: Dmitry
Date:
Subject: Re: IPC/MultixactCreation on the Standby server
Next
From: Zane Duffield
Date:
Subject: Check for existing replication slot in pg_createsubscriber