Re: Should we update the random_page_cost default value?
От | Michael Banck |
---|---|
Тема | Re: Should we update the random_page_cost default value? |
Дата | |
Msg-id | 68e385b0.5d0a0220.de80b.d3f9@mx.google.com обсуждение исходный текст |
Ответ на | 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 |
Hi, On Mon, Oct 06, 2025 at 02:59:16AM +0200, Tomas Vondra wrote: > I started looking at how we calculated the 4.0 default back in 2000. > Unfortunately, there's a lot of info, as Tom pointed out in 2024 [2]. > But he outlined how the experiment worked: > > - generate large table (much bigger than RAM) > - measure runtime of seq scan > - measure runtime of full-table index scan > - calculate how much more expensive a random page access is Ok, but I also read somewhere (I think it might have been Bruce in a recent (last few years) discussion of random_page_cost) that on top of that, we assumed 90% (or was it 95%?) of the queries were cached in shared_buffers (probably preferably the indexes), so that while random access is massively slower than sequential access (surely not 4x by 2000) is offset by that. I only quickly read your mail, but I didn't see any discussion of caching on first glance, or do you think it does not matter much? Michael
В списке pgsql-hackers по дате отправления: