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
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 |