Re: Should we update the random_page_cost default value? - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Should we update the random_page_cost default value?
Date
Msg-id aOb-1meWdbrFNvhT@momjian.us
Whole thread Raw
In response to Re: Should we update the random_page_cost default value?  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Should we update the random_page_cost default value?
List pgsql-hackers
On Mon, Oct  6, 2025 at 12:57:20PM -0400, Bruce Momjian wrote:
> On Mon, Oct  6, 2025 at 11:14:13AM -0400, Andres Freund wrote:
> > I'd guess that the *vast* majority of PG workloads these days run on networked
> > block storage. For those typically the actual latency at the storage level is
> > a rather small fraction of the overall IO latency, which is instead dominated
> > by network and other related cost (like the indirection to which storage
> > system to go to and crossing VM/host boundaries).  Because the majority of the
> > IO latency is not affected by the storage latency, but by network lotency, the
> > random IO/non-random IO difference will play less of a role.
> 
> Yes, the last time we discussed changing the default random page cost,
> September 2024, the argument was that while SSDs should be < 4, cloud
> storage might be > 4, so 4 was still a good value:
> 
>     https://www.postgresql.org/message-id/flat/877caxaxt6.fsf%40wibble.ilmari.org#8a10b7b8cf05410291d076f8def58c29
> 
> Add in cache effects for all of these storage devices as outlined in our
> docs.

I rewrote the random_page_cost docs, attached, to remove a focus on
magnetic disk, and added network latency as a reason for
random_page_cost being low.  I removed the specific caching numbers and
went with a more generic description.

I would normally apply this only to master, but given the complaints in
this thread, maybe I should backpatch it.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

Attachment

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: another autovacuum scheduling thread
Next
From: Jeremy Schneider
Date:
Subject: Re: another autovacuum scheduling thread