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

From Jakub Wartak
Subject Re: Should we update the random_page_cost default value?
Date
Msg-id CAKZiRmxm218P4anzjaAeeJW-ydtmM30EZRRtgGQtTMwgRze1hQ@mail.gmail.com
Whole thread Raw
In response to Re: Should we update the random_page_cost default value?  (Tomas Vondra <tomas@vondra.me>)
List pgsql-hackers
On Mon, Oct 6, 2025 at 11:24 AM Tomas Vondra <tomas@vondra.me> wrote:
>
> On 10/6/25 07:29, Tom Lane wrote:
> > Tomas Vondra <tomas@vondra.me> writes:
[..]
>
> > Another angle is that I expect that the ongoing AIO work will largely
> > destroy the existing model altogether, at least if you think in terms
> > of the model as trying to predict query execution time.
[..]
> That is, estimate the I/O concurrency and lower the cost a bit?

Side question, out of curiosity: didn't the ship already sail with
introduction of streaming read API back in a while ago? After all, the
io_combine_limit with vectored preadv() has the ability to greatly
accelerate seq scans (that would mean batching up to 16 syscalls while
the kernel is doing its own magic in the background anyway - with
merging/splitting/readaheads). To me it looks like you are
experiencing heavy concurrency benefits at least on that `NVMe/RAID0`
testcase, so one question would be: does the default random_page_cost
be also that inaccurate earlier, on e.g. PG16?

-J.



pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Logical Replication of sequences
Next
From: "Aya Iwata (Fujitsu)"
Date:
Subject: RE: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE