Re: Unexpected Performance for the Function simplify_function

>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(at)gmail(dot)com>
Sent: Friday, October 25, 2024 4:13 AM
To: Ba Jinsheng <bajinsheng(at)u(dot)nus(dot)edu>
Cc: pgsql-performance(at)lists(dot)postgresql(dot)org <pgsql-performance(at)lists(dot)postgresql(dot)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.