Re: Should we update the random_page_cost default value?
| От | Tomas Vondra |
|---|---|
| Тема | Re: Should we update the random_page_cost default value? |
| Дата | |
| Msg-id | 9263e806-c937-43b7-b6c2-04d23ecc4f52@vondra.me обсуждение исходный текст |
| Ответ на | Re: Should we update the random_page_cost default value? (Tomas Vondra <tomas@vondra.me>) |
| Ответы |
Re: Should we update the random_page_cost default value?
|
| Список | pgsql-hackers |
On 10/8/25 12:01, Tomas Vondra wrote:
> 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 ...
>
I did a run on PG17 (on the NVMe RAID), and it's not all that different
from PG18:
seqscan (s) index scan (s) random_page_cost
-----------------------------------------------------------------
PG18 NVMe/RAID0 24 25462 49.3
PG17 NVMe/RAID0 32 25533 38.2
Yes, there's a difference, mostly due to seqscans being slower on PG17
(which matches the measurements in the io_method thread). It'd be a bit
slower with checksums enabled on PG17 (by ~10-20%).
It's just a single run, from a single hw configuration. But the results
are mostly as I expected.
regards
--
Tomas Vondra
В списке pgsql-hackers по дате отправления: