Re: Should we update the random_page_cost default value?

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Greg Sabino Mullane <htamfids(at)gmail(dot)com>, Robert Treat <rob(at)xzilla(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Tomas Vondra <tomas(at)vondra(dot)me>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Should we update the random_page_cost default value?
Date: 2025-10-07 21:08:36
Message-ID: CAH2-WznjjrwjHfJjnVYuMPO5A50XasEsMoia9Q-7oW_r4_9C9g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 7, 2025 at 3:46 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> I think this discrepancy is largely due to the fact that Tomas' is testing
> with a cold cache (he has numbers for both), whereas most production workloads
> have very high cache hit ratios.

Any test case that fails to ensure that all relevant indexes at least
have all of their internal B-Tree pages in shared_buffers is extremely
unrealistic. That only requires that we cache only a fraction of 1% of
all index pages, which is something that production workloads manage
to do approximately all the time.

I wonder how much the "cold" numbers would change if Tomas made just
that one tweak (prewarming only the internal index pages). I don't
think that there's a convenient way of running that experiment right
now -- but it would be relatively easy to invent one.

I'm not claiming that this extra step would make the "cold" numbers
generally representative. Just that it might be enough on its own to
get wildly better results, which would put the existing "cold" numbers
in context.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Melanie Plageman 2025-10-07 21:10:02 Re: Fix overflow of nbatch
Previous Message Tom Lane 2025-10-07 20:15:24 Re: Optimize LISTEN/NOTIFY