Re: Unexpected Performance for the Function simplify_function

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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-26 06:28:16
Message-ID: 3130756.1729924096@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Ba Jinsheng <bajinsheng(at)u(dot)nus(dot)edu> 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.

> I used the default configuration in the file src/backend/utils/misc/postgresql.conf.sample
> So the random_page_cost = 4.0

You're still admitting to nothing as to the hardware you are running
this test on.

However, 4.0 is a number we chose decades ago based on typical
performance of spinning-rust storage. It's not very appropriate
for SSD or similar storage -- numbers just a bit above 1 are
probably the most appropriate thing for that kind of storage.
(There are ongoing discussions about changing the setting's default
value, but so far not backed by any great deal of hard evidence.)

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Ba Jinsheng 2024-10-26 07:31:36 Re: Unexpected Performance for the Function simplify_function
Previous Message Pavel Stehule 2024-10-25 20:38:01 Re: proposal: schema variables