Re: Unexpected Performance for the Function simplify_function
От | Andrei Lepikhov |
---|---|
Тема | Re: Unexpected Performance for the Function simplify_function |
Дата | |
Msg-id | 00525dcd-78ec-446c-ba96-f6430b89a08c@gmail.com обсуждение исходный текст |
Ответ на | Unexpected Performance for the Function simplify_function (Ba Jinsheng <bajinsheng@u.nus.edu>) |
Ответы |
Re: Unexpected Performance for the Function simplify_function
|
Список | pgsql-performance |
On 10/25/24 02:43, Ba Jinsheng wrote: > I am not proposing a fixing patch, as the patch is incorrect. Instead, I > just want to show disabling the simplify_function() function brings > performance benefit, and it seems unexpected. I am wondering whether we > can optimize simplify_function() to make the performance better for this > workload? I also discovered your case. Using AQO and settling the correct cardinalities in each node, I found that the plan doesn't change at all. So, I wonder if you could analyse the path-choosing logic, determine the costs of competing paths, and explain why NestLoop wasn't chosen. Maybe there is kind of early selectivity estimation error or something even more deep: specific tuples distribution across blocks of the heap table. -- regards, Andrei Lepikhov
В списке pgsql-performance по дате отправления: