Re: Unexpected Performance for the Function simplify_function - Mailing list pgsql-performance

From Andrei Lepikhov
Subject Re: Unexpected Performance for the Function simplify_function
Date
Msg-id 00525dcd-78ec-446c-ba96-f6430b89a08c@gmail.com
Whole thread Raw
In response to Unexpected Performance for the Function simplify_function  (Ba Jinsheng <bajinsheng@u.nus.edu>)
Responses Re: Unexpected Performance for the Function simplify_function
List 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 by date:

Previous
From: Greg Sabino Mullane
Date:
Subject: Re: Unexpected Performance for the Function simplify_function
Next
From: James Pang
Date:
Subject: lwlock:LockManager wait_events