Re: Removing unneeded self joins
От | Alexander Korotkov |
---|---|
Тема | Re: Removing unneeded self joins |
Дата | |
Msg-id | CAPpHfdsz8E085YF2VoJe2+h4YAShsh7p--t3kQfQTntiCy63Xg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Removing unneeded self joins (Andrei Lepikhov <a.lepikhov@postgrespro.ru>) |
Ответы |
Re: Removing unneeded self joins
|
Список | pgsql-hackers |
On Thu, Oct 19, 2023 at 6:16 AM Andrei Lepikhov <a.lepikhov@postgrespro.ru> wrote: > On 19/10/2023 01:50, Alexander Korotkov wrote: > > This query took 3778.432 ms with self-join removal disabled, and > > 3756.009 ms with self-join removal enabled. So, no measurable > > overhead. Similar to the higher number of joins. Can you imagine > > some extreme case when self-join removal could introduce significant > > overhead in comparison with other optimizer parts? If not, should we > > remove self_join_search_limit GUC? > Thanks, > It was Zhihong Yu who worried about that case [1]. And my purpose was to > show a method to avoid such a problem if it would be needed. > I guess the main idea here is that we have a lot of self-joins, but only > few of them (or no one) can be removed. > I can't imagine a practical situation when we can be stuck in the > problems here. So, I vote to remove this GUC. I've removed the self_join_search_limit. Anyway there is enable_self_join_removal if the self join removal algorithm causes any problems. I also did some grammar corrections for the comments. I think the patch is getting to the committable shape. I noticed some failures on commitfest.cputube.org. I'd like to check how this version will pass it. ------ Regards, Alexander Korotkov
Вложения
В списке pgsql-hackers по дате отправления: