Re: Clock sweep not caching enough B-Tree leaf pages?
От | Merlin Moncure |
---|---|
Тема | Re: Clock sweep not caching enough B-Tree leaf pages? |
Дата | |
Msg-id | CAHyXU0xFTghg3iSJZWU_-LiFt+7rq3TKJqqS+xzt-iO19=kLvA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Clock sweep not caching enough B-Tree leaf pages? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Clock sweep not caching enough B-Tree leaf pages?
|
Список | pgsql-hackers |
On Wed, Apr 16, 2014 at 1:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Merlin Moncure <mmoncure@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 bgwritercycle. */ uint32 completePasses; /* Complete cycles of the clock sweep */ uint32 numBufferAllocs; /* Buffers allocated since last reset */ merlin
В списке pgsql-hackers по дате отправления: