Re: Non-deterministic buffer counts reported in execution with EXPLAIN ANALYZE BUFFERS

Thank you all for the time and detailed responses. To clarify - RegreSQL
works with tolerances and I only came across this when detecting
improvements (i.e. opposite of the regressions), where smaller executions
showed consistent "gains" that turned out to be cache
related. Understanding the complexity of the underlying cause is in a way
enough for me - there's much more depth here than I initially anticipated.
My warm up fix attempts led me to believe it might be much easier.

I'll be honest - just understanding and reviewing Lukas' patches will take
me a few weeks to properly digest. But at the end it's exactly the kind of
deeper understanding I was hoping to build by engaging here.

I really do appreciate the patience with a first-time poster :)

Radim

On Thu, 5 Feb 2026 at 16:25, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Tomas Vondra <tomas(at)vondra(dot)me> writes:
> > On 2/5/26 01:15, David Rowley wrote:
> >> I imagined if it's just for machines running tests then you could just
> >> load everything. If it was coded in such a way that a tuple fetched by
> >> doing a Seq Scan on the catalogue table was what went into the cache,
> >> rather than the Seq Scan drives the normal cache lookup code,
> >> resulting in a subsequent Index Scan on the catalogue's index, then it
> >> could be done with fairly low overhead. I imagine in the order of
> >> <10ms from fresh initdb. That doesn't seem excessively long for
> >> machines running tests in the background.
>
> > So we'd just go through all the caches relcaches/catcaches/... and load
> > all the stuff that's in pg_catalog? I guess that could work,
>
> ... until there's a cache flush event. This whole discussion seems
> to me to be based on a misconception.
>
> regards, tom lane
>