Changing the default random_page_cost value - Mailing list pgsql-hackers

From Greg Sabino Mullane
Subject Changing the default random_page_cost value
Date
Msg-id CAKAnmmK_nSPYr53LobUwQD59a-8U9GEC3XGJ43oaTYJq5nAOkw@mail.gmail.com
Whole thread Raw
Responses Re: Changing the default random_page_cost value
Re: Changing the default random_page_cost value
List 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

pgsql-hackers by date:

Previous
From: Eric Ridge
Date:
Subject: IndexAccessMethod API & Index Only Scans
Next
From: Roberto Mello
Date:
Subject: Re: Changing the default random_page_cost value