Re: Non-deterministic buffer counts reported in execution with EXPLAIN ANALYZE BUFFERS
| От | Tom Lane |
|---|---|
| Тема | Re: Non-deterministic buffer counts reported in execution with EXPLAIN ANALYZE BUFFERS |
| Дата | |
| Msg-id | 1613669.1770305125@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Non-deterministic buffer counts reported in execution with EXPLAIN ANALYZE BUFFERS (Tomas Vondra <tomas@vondra.me>) |
| Ответы |
Re: Non-deterministic buffer counts reported in execution with EXPLAIN ANALYZE BUFFERS
|
| Список | 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 по дате отправления: