Re: Should we update the random_page_cost default value?

On 10/6/25 07:29, Tom Lane wrote:
> Tomas Vondra <tomas(at)vondra(dot)me> writes:
>> I wonder if it's time to consider updating the random_page_cost default
>> value. There are multiple reasons to maybe do that.
>
> Re-reading the old links you provided, I was reminded that the 4.0
> value came in with some fairly fundamental changes to the cost model,
> such as accounting for WHERE-clause evaluation explicitly instead of
> assuming that it was down in the noise. I can't help wondering if
> it's time for another rethink of what the cost model is, rather than
> just messing with its coefficients. I don't have any concrete ideas
> about what that should look like, though.
>

True, maybe it's time for a larger revision. Do you have any thoughts on
how it should be changed? (I don't, but I didn't have the ambition.)

> 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. But if what
> we're trying to model is net resource demands, with an eye to
> minimizing the total system load not execution time of any one query,
> maybe we can continue to work with something close to what we've
> traditionally done.
>
> No answers here, just more questions ...
>

I had the same thought, when working on the (index) prefetching. Which
of course now relies on AIO. Without concurrency, there wasn't much
difference between optimizing for resources and time, but AIO changes
that. In fact, parallel query has a similar effect, because it also
spreads the work to multiple concurrent processes.

Parallel query simply divides the cost between workers, as if each use a
fraction of resources. And the cost of the parallel plan is lower than
summing up the per-worker costs. Maybe AIO should do something similar?
That is, estimate the I/O concurrency and lower the cost a bit?

regards

--
Tomas Vondra