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