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

From Tomas Vondra
Subject Re: Should we update the random_page_cost default value?
Date
Msg-id 3400df27-4f2a-4f27-834a-5f7ba058f26d@vondra.me
Whole thread Raw
In response to Re: Should we update the random_page_cost default value?  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: Should we update the random_page_cost default value?
List pgsql-hackers
On 10/8/25 06:02, David Rowley wrote:
> On Wed, 8 Oct 2025 at 08:15, Greg Sabino Mullane <htamfids@gmail.com> wrote:
>> I've been doing this sort of thing for clients a long time, and I always test both directions when I come across a
querythat should be faster. For real-world queries, 99% of them have no change or improve with a lowered rpc, and 99%
getworse via a raised rpc. So color me unconvinced.
 
> 
> I wonder how much past experience for this on versions before v18
> count in now that we have AIO. The bar should have moved quite
> significantly with v18 in terms of how often Seq Scans spend waiting
> for IO vs Index Scans. So maybe Tomas's results shouldn't be too
> surprising. Maybe the graph would look quite different with io_method
> = 'sync'.. ?
> 

Interesting idea, and I'll try to run this on 17 and/or on 18/sync. I
should have some results tomorrow.

But based on the testing I've done on 18beta1 (in the thread about what
should be the default for io_method), I doubt it'll change the outcome
very much. It showed no change for indexscans, and seqscans got about 2x
as fast. So the random_page_cost will be about 1/2 of what the earlier
results said - that's a change, but it's still more than 2x of the
current value.

Let's see if the results agree with my guess ...


regards

-- 
Tomas Vondra




pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Logical Replication of sequences
Next
From: Álvaro Herrera
Date:
Subject: Re: pg_createsubscriber --dry-run logging concerns