Re: Should we update the random_page_cost default value?
| От | Bruce Momjian | 
|---|---|
| Тема | Re: Should we update the random_page_cost default value? | 
| Дата | |
| Msg-id | aOP08LIFZsmxp8Jn@momjian.us обсуждение исходный текст  | 
		
| Ответ на | Re: Should we update the random_page_cost default value? (Andres Freund <andres@anarazel.de>) | 
| Ответы | 
                	
            		Re: Should we update the random_page_cost default value?
            		
            		 Re: Should we update the random_page_cost default value?  | 
		
| Список | pgsql-hackers | 
On Mon, Oct  6, 2025 at 11:14:13AM -0400, Andres Freund wrote:
> > It obviously contradicts the advice to set the value closer to 1.0. But
> > why is that? SSDs are certainly better with random I/0, even if the I/O
> > is not concurrent and the SSD is not fully utilized. So the 4.0 seems
> > off, the value should be higher than what we got for SSDs ...
> 
> 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.
-- 
  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.
		
	В списке pgsql-hackers по дате отправления: