Re: Unexpected Performance for the Function simplify_function

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

In response to

Responses

Browse pgsql-performance by date

  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