Re: Should we update the random_page_cost default value?
От | Jakub Wartak |
---|---|
Тема | Re: Should we update the random_page_cost default value? |
Дата | |
Msg-id | CAKZiRmxm218P4anzjaAeeJW-ydtmM30EZRRtgGQtTMwgRze1hQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Should we update the random_page_cost default value? (Tomas Vondra <tomas@vondra.me>) |
Список | 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 по дате отправления: