>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 <lepi...@gmail.com>
Sent: Friday, October 25, 2024 4:13 AM
To: Ba Jinsheng <bajinsh...@u.nus.edu>
Cc: pgsql-performance@lists.postgresql.org
<pgsql-performance@lists.postgresql.org>
Subject: Re: Unexpected Performance for the Function simplify_function
- External Email -
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
Notice: This email is generated from the account of an NUS alumnus. Contents,
views, and opinions therein are solely those of the sender.
