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
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 |