sheng Ba
From: Tom Lane
Sent: Saturday, October 26, 2024 8:28 AM
To: Ba Jinsheng
Cc: pgsql-performance@lists.postgresql.org
Subject: Re: Unexpected Performance for the Function simplify_function
- External Email -
Ba Jinsheng writes:
>> It looks like the better p
Ba Jinsheng writes:
>> It looks like the better plan involves a
>> nestloop with inner indexscan on lineitem, which is something whose
>> estimated cost depends enormously on random_page_cost. You've given
>> us exactly zero detail about your test conditions, so it's hard to say
>> more than that
Hello,
The query plans and results you shared illustrate the unexpected
performance differences between using and bypassing the simplify_function()
logic in PostgreSQL’s optimizer. Here’s an in-depth analysis and thoughts
on optimizing this scenario:
*Overview of the Problem*
The purpose of s
On Fri, 25 Oct 2024 at 22:26, Ba Jinsheng wrote:
> I guess the better query plan is not considered when comparing the cost of
> paths?
You might want to change effective_cache_size is set high enough.
Something like 50-75% of RAM is likely fine.
David
On 10/25/24 16:26, Ba Jinsheng wrote:
>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
>It looks like the better plan involves a
>nestloop with inner indexscan on lineitem, which is something whose
>estimated cost depends enormously on random_page_cost. You've given
>us exactly zero detail about your test conditions, so it's hard to say
>more than that.
I used the default configura
Jinsheng Ba
From: Andrei Lepikhov
Sent: Friday, October 25, 2024 4:13 AM
To: Ba Jinsheng
Cc: pgsql-performance@lists.postgresql.org
Subject: Re: Unexpected Performance for the Function simplify_function
- External Email -
On 10/25/24 02:43, Ba
Dear PostgreSQL Community,
For the query 10 in TPC-H benchmark:
select
c_custkey,
c_name,
sum(l_extendedprice * (1 - l_discount)) as revenue,
c_acctbal,
n_name,
c_address,
c_phone,
c_comment
from
CUSTOMER,
ORDERS,
LINEITEM,
NA
On Thursday, October 24, 2024, Tom Lane wrote:
> Shiv Iyer writes:
> > The query plans and results you shared illustrate the unexpected
> > performance differences between using and bypassing the
> simplify_function()
> > logic in PostgreSQL’s optimizer. Here’s an in-depth analysis and thoughts
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
Ba Jinsheng writes:
> 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 performan
Shiv Iyer writes:
> The query plans and results you shared illustrate the unexpected
> performance differences between using and bypassing the simplify_function()
> logic in PostgreSQL’s optimizer. Here’s an in-depth analysis and thoughts
> on optimizing this scenario:
Just out of curiosity, was
On Thu, Oct 24, 2024 at 3:49 PM Shiv Iyer wrote:
> Hello,
>
>
> The query plans and results you shared illustrate the unexpected
> performance differences between using and bypassing the
> simplify_function() logic in PostgreSQL’s optimizer. Here’s an in-depth
> analysis and thoughts on optimizin
13 matches
Mail list logo
