| From: | Michael Banck <mbanck(at)gmx(dot)net> |
|---|---|
| To: | Tomas Vondra <tomas(at)vondra(dot)me> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Should we update the random_page_cost default value? |
| Date: | 2025-10-06 09:02:39 |
| Message-ID: | 68e385b0.5d0a0220.de80b.d3f9@mx.google.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | John Naylor | 2025-10-06 09:04:00 | get rid of RM_HEAP2_ID |
| Previous Message | Andrey Borodin | 2025-10-06 09:00:47 | Re: Allow reading LSN written by walreciever, but not flushed yet |