Re: Non-deterministic buffer counts reported in execution with EXPLAIN ANALYZE BUFFERS - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Non-deterministic buffer counts reported in execution with EXPLAIN ANALYZE BUFFERS
Date
Msg-id 1613669.1770305125@sss.pgh.pa.us
Whole thread Raw
In response to Re: Non-deterministic buffer counts reported in execution with EXPLAIN ANALYZE BUFFERS  (Tomas Vondra <tomas@vondra.me>)
List pgsql-hackers
Tomas Vondra <tomas@vondra.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



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Non-deterministic buffer counts reported in execution with EXPLAIN ANALYZE BUFFERS
Next
From: Peter Geoghegan
Date:
Subject: Re: Remove header lock BufferGetLSNAtomic() on architectures with 64 bit atomic operations