Re: Removing unneeded self joins
От | Alexander Korotkov |
---|---|
Тема | Re: Removing unneeded self joins |
Дата | |
Msg-id | CAPpHfdtpLv98ydqRhWAa9QLmh6m_cqmBy5YZT0Scax9FGZrh6Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Removing unneeded self joins (jian he <jian.universality@gmail.com>) |
Ответы |
Re: Removing unneeded self joins
|
Список | pgsql-hackers |
On Thu, Jul 4, 2024 at 5:15 AM jian he <jian.universality@gmail.com> wrote: > in remove_self_join_rel, i have > ```ChangeVarNodes((Node *) root->parse, toRemove->relid, toKeep->relid, 0);``` > which will change the joinlist(RangeTblRef) from (1,2) to (2,2). > Immediately after this call, I wrote a function (restore_rangetblref) > to restore the joinlist as original (1,2). > then remove_rel_from_joinlist won't error out. > see remove_self_join_rel, restore_rangetblref. Thank you, now this is clear. Could we add additional parameters to ChangeVarNodes() instead of adding a new function which reverts part of changes. > current mechanism, in this example context, > SJE can translate ```update test set val = t.val + 1 from test t where > test.id = t.id;``` as good as to > ```update test set val = val + 1```. > if we replace it that way, then this example would result val = 3. > > but without SJE, > ```update test set val = t.val + 1 from test t where test.id = t.id;``` > will result val = 2. > > you mentioned the EPQ problem, previously i don't know what that means. Yes, I guessed so. I should have come with more detailed explanation. > now i see, I feel like it is quite challenging to resolve it. Yep. Glad to see we are on the same page. This is why I think we could leave SJE for target relation of modification queries for future. I'd like to not devalue SELECT-only SJE, given that this is a step forward anyway. ------ Regards, Alexander Korotkov Supabase
В списке pgsql-hackers по дате отправления: