|
>So, I wonder if you could analyse the path-choosing logic, determine the
costs of competing paths, and explain why NestLoop wasn't chosen.
To be honest, it is a bit challenging for me.
I guess the better query plan is not considered when comparing the cost of paths?
Best regards, Jinsheng Ba
From: Andrei Lepikhov <lepihov@xxxxxxxxx>
Sent: Friday, October 25, 2024 4:13 AM To: Ba Jinsheng <bajinsheng@xxxxxxxxx> Cc: pgsql-performance@xxxxxxxxxxxxxxxxxxxx <pgsql-performance@xxxxxxxxxxxxxxxxxxxx> Subject: Re: Unexpected Performance for the Function simplify_function - External Email -
Notice: This email is generated from the account of an NUS alumnus. Contents, views, and opinions therein are solely those of the sender.
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 |
