Re: Some problems regarding the self-join elimination code
От | Andrei Lepikhov |
---|---|
Тема | Re: Some problems regarding the self-join elimination code |
Дата | |
Msg-id | 6b4ef6ec-05f4-436a-a2e8-6b4748ddd4c6@gmail.com обсуждение исходный текст |
Ответ на | Re: Some problems regarding the self-join elimination code (Andrei Lepikhov <lepihov@gmail.com>) |
Ответы |
Re: Some problems regarding the self-join elimination code
|
Список | pgsql-hackers |
On 4/10/25 14:39, Andrei Lepikhov wrote: > On 4/10/25 13:36, Alexander Korotkov wrote: >> On Wed, Apr 9, 2025 at 10:39 AM Andrei Lepikhov <lepihov@gmail.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. To provide some food for thought, here is a draft in attachment which addresses both issues: RestrictInfo relid replacement and move SJE-specific code out of the ChangeVarNodes routine (callback approach). -- regards, Andrei Lepikhov
Вложения
В списке pgsql-hackers по дате отправления: