Re: Increase default maintenance_io_concurrency to 16 - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Increase default maintenance_io_concurrency to 16
Date
Msg-id rdd4m4fze6zt4fjmp2p2ez5smokglno7pqefloyiql36kkudw6@pwpmabadygqz
Whole thread Raw
In response to Increase default maintenance_io_concurrency to 16  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Increase default maintenance_io_concurrency to 16
List pgsql-hackers
Hi,

On 2025-03-18 16:22:45 -0400, Bruce Momjian wrote:
> On Tue, Mar 18, 2025 at 04:13:26PM -0400, Andres Freund wrote:
> > Hi,
> > 
> > On 2025-03-18 16:08:22 -0400, Bruce Momjian wrote:
> > > This commit makes our default random_page_cost = 4 out of line with
> > > these new settings (assumes modern SSD/NAS/SAN hardware) and more out of
> > > line with reality.
> > 
> > How so? That seems like an independent consideration to me.
> 
> [thread moved to hackers]
> 
> Uh, I think our old random_page_cost and *_io_concurrency assumed
> magnetic disks --- now *_io_concurrency assumes more modern hardware and
> random_page_cost assumes magnetic.

The cost difference between random and non-random IO is actually still
reasonably accurate with NVMEs. You can argue that random_page_cost should be
2.5, but that really depends on the specific hardware.

Particularly for cloud style networked storage, you could even argue that the
difference between sequential and random IO has *grow* given recent changes in
PG (io combining in PG 17), as random IOs much more quickly lead to exhausting
IOPS quotas.

I still don't think adjusting random_page_cost has any meaningful relation to
the change at hand.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Increase default maintenance_io_concurrency to 16
Next
From: Robert Haas
Date:
Subject: Re: Update Unicode data to Unicode 16.0.0