From: | Greg Sabino Mullane <htamfids(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Changing the default random_page_cost value |
Date: | 2024-09-27 14:07:14 |
Message-ID: | CAKAnmmK_nSPYr53LobUwQD59a-8U9GEC3XGJ43oaTYJq5nAOkw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
tl;dr let's assume SSDs are popular and HDDs are the exception and flip our
default
As I write this email, it's the year 2024. I think it is time we lower our
"default" setting of random_page_cost (as set in postgresql.conf.sample and
the docs). Even a decade ago, the current default of 4 was considered
fairly conservative and often lowered. The git logs shows that this value
was last touched in 2006, during the age of spinning metal. We are now in a
new era, the age of SSDs, and thus we should lower this default value to
reflect the fact that the vast majority of people using Postgres these days
are doing so on solid state drives. We tend to stay ultra-conservative in
all of our settings, but we also need to recognize when there has been a
major shift in the underlying hardware - and calculations that our defaults
are based on.
Granted, there are other factors involved, and yes, perhaps we should tweak
some of the similar settings as well, but ranom_page_cost is the one
setting most out of sync with today's hardware realities. So I'll be brave
and throw a number out there: 1.2. And change our docs to say wordage like
"if you are using an older hard disk drive technology, you may want to try
raising rpc" to replace our fairly-hidden note about SSDs buried in the
last sentence - of the fourth paragraph - of the rpc docs.
Real data about performance on today's SSDs are welcome, and/or some way to
generate a more accurate default.
Cheers,
Greg
From | Date | Subject | |
---|---|---|---|
Next Message | Roberto Mello | 2024-09-27 14:26:38 | Re: Changing the default random_page_cost value |
Previous Message | Alexander Korotkov | 2024-09-27 14:07:09 | Re: pgsql: Implement pg_wal_replay_wait() stored procedure |