From: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
---|---|
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 |
Date: | 2024-10-25 02:13:34 |
Message-ID: | 00525dcd-78ec-446c-ba96-f6430b89a08c@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2024-10-25 05:21:34 | Re: proposal: schema variables |
Previous Message | Greg Sabino Mullane | 2024-10-24 23:09:06 | Re: Unexpected Performance for the Function simplify_function |