On Wed, Apr 16, 2014 at 1:44 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Merlin Moncure <mmonc...@gmail.com> writes:
>> Anyways, I'm still curious if you can post similar numbers basing the
>> throttling on gross allocation counts instead of time. Meaning: some
>> number of buffer allocations has to have occurred before you consider
>> eviction. Besides being faster I think it's a better implementation:
>> an intermittently loaded server will give more consistent behavior.
>
> Yeah --- I think wall-clock-based throttling is fundamentally the wrong
> thing anyway. Are we going to start needing a CPU speed measurement to
> tune the algorithm with? Not the place to be going. But driving it off
> the number of allocations that've been done could be sensible. (OTOH,
> that means you need a central counter, which itself would be a
> bottleneck.)
sure -- note we already track that in BufferStrategyControl
(everything in buffer allocation is already centrally managed
essentially).
/*
* Statistics. These counters should be wide enough that they can't
* overflow during a single bgwriter cycle.
*/
uint32 completePasses; /* Complete cycles of the clock sweep */
uint32 numBufferAllocs; /* Buffers allocated
since last reset */
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
