Re: Should we update the random_page_cost default value?

From: Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>
To: Tomas Vondra <tomas(at)vondra(dot)me>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Should we update the random_page_cost default value?
Date: 2025-10-06 11:04:36
Message-ID: CAKZiRmxm218P4anzjaAeeJW-ydtmM30EZRRtgGQtTMwgRze1hQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 6, 2025 at 11:24 AM Tomas Vondra <tomas(at)vondra(dot)me> wrote:
>
> On 10/6/25 07:29, Tom Lane wrote:
> > Tomas Vondra <tomas(at)vondra(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Aya Iwata (Fujitsu) 2025-10-06 11:21:02 RE: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE
Previous Message vignesh C 2025-10-06 11:03:42 Re: Logical Replication of sequences