Re: Removing unneeded self joins
От | Andrei Lepikhov |
---|---|
Тема | Re: Removing unneeded self joins |
Дата | |
Msg-id | 6e17d257-68d7-44f0-a54b-0ea49bfd1dbd@gmail.com обсуждение исходный текст |
Ответ на | Re: Removing unneeded self joins (Michael Paquier <michael@paquier.xyz>) |
Список | 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 по дате отправления: