Re: Some problems regarding the self-join elimination code
От | Andrei Lepikhov |
---|---|
Тема | Re: Some problems regarding the self-join elimination code |
Дата | |
Msg-id | 2d8756ba-a973-455b-b7ae-c55d85d96777@gmail.com обсуждение исходный текст |
Ответ на | Re: Some problems regarding the self-join elimination code (Richard Guo <guofenglinux@gmail.com>) |
Ответы |
Re: Some problems regarding the self-join elimination code
|
Список | pgsql-hackers |
On 4/9/25 04:05, Richard Guo wrote: > On Tue, Apr 8, 2025 at 11:12 PM Dean Rasheed <dean.a.rasheed@gmail.com> wrote: >> On Tue, 8 Apr 2025 at 12:31, Andrei Lepikhov <lepihov@gmail.com> wrote: >> Perhaps the way to do it is to make ChangeVarNodesExtended() take a >> callback function to be invoked for each node visited. The callback >> (which would then be in the planner, with the other SJE code) would do >> any special handling it needed (for RangeTblRef and RestrictInfo >> nodes), and call ChangeVarNodes_walker() for any other types of node, >> to get the default behaviour. > > Yeah, this might be a better approach. Perhaps we can borrow some > ideas from replace_rte_variables. 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? [1] https://www.postgresql.org/message-id/3622801.1715010885%40sss.pgh.pa.us -- regards, Andrei Lepikhov
В списке pgsql-hackers по дате отправления: