From: Tom Lane <tgl@sss.pgh.pa.us>
To: Bruce Momjian <bruce@momjian.us>
cc: Andres Freund <andres@anarazel.de>,
        Melanie Plageman <melanieplageman@gmail.com>,
        PostgreSQL-development <pgsql-hackers@lists.postgresql.org>,
        Greg Smith <greg.smith@crunchydata.com>
Subject: Re: Increase default maintenance_io_concurrency to 16
In-reply-to: <Z9njbVYyzxX0cgIr@momjian.us>
References: <E1tuWgZ-0035xZ-0x@gemulon.postgresql.org>
 <Z9nStg5TJssYfg_b@momjian.us>
 <fycuaxeisofdyv4265ejiluixuklmoaaoywa7nhz3heytf4na6@3vd6owgwvadc>
 <Z9nWFVBx3OJSwqg6@momjian.us>
 <rdd4m4fze6zt4fjmp2p2ez5smokglno7pqefloyiql36kkudw6@pwpmabadygqz>
 <Z9nZET_03i2CQ1tP@momjian.us>
 <4p7gtb2nfr3njhgq7bmpe24unsbyoerlom7zrcu5sl2vyyutlp@ol5ywrm7j5ok>
 <Z9njbVYyzxX0cgIr@momjian.us>
Comments: In-reply-to Bruce Momjian <bruce@momjian.us>
	message dated "Tue, 18 Mar 2025 17:19:41 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <586811.1742334443.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 18 Mar 2025 17:47:23 -0400
Message-ID: <586812.1742334443@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/586812.1742334443%40sss.pgh.pa.us>
Precedence: bulk

Bruce Momjian <bruce@momjian.us> writes:
>>> https://www.postgresql.org/docs/current/runtime-config-query.html#RUNT=
IME-CONFIG-QUERY-CONSTANTS
>>> =

>>> Random access to mechanical disk storage is normally much more expensi=
ve
>>> than four times sequential access. However, a lower default is used
>>> (4.0) because the majority of random accesses to disk, such as indexed
>>> reads, are assumed to be in cache. The default value can be thought of
>>> as modeling random access as 40 times slower than sequential, while
>>> expecting 90% of random reads to be cached.

This explanation is, in fact, made up out of whole cloth.  It has
diddly-squat to do with where the number came from, although maybe
it's an okay rationalization for continuing to use 4.0 on modern
hardware.

Where the number came from is that I did a bunch of testing back in
the late 90s and random_page_cost =3D 4.0 made the planner's ratios of
seqscan vs indexscan costs match up with observed timings.  Of course,
those observations were made with spinning-rust drives, so you'd not
get the same results on SSDs.

> Yes, I can't say there is much research behind the value, and even if
> there was, the assumed hardware is unlikely to be relevant today.

Yes as to the latter, no as to the former.

			regards, tom lane