Re: Clock sweep not caching enough B-Tree leaf pages?

On 4/28/14, 8:04 AM, Robert Haas wrote:
> On Mon, Apr 21, 2014 at 6:38 PM, Jim Nasby <jim(at)nasby(dot)net> wrote:
>>> I feel that if there is no memory pressure, frankly it doesnt matter much
>>> about what gets out and what not. The case I am specifically targeting is
>>> when the clocksweep gets to move about a lot i.e. high memory pressure
>>> workloads. Of course, I may be totally wrong here.
>>
>> Well, there's either memory pressure or there isn't. If there isn't then
>> it's all moot *because we're not evicting anything*.
>
> I don't think that's really true. A workload can fit within
> shared_buffers at some times and spill beyond it at others. Every
> time it fits within shared_buffers for even a short period of time,
> the reference count of any buffer that's not ice-cold goes to 5 and we
> essentially lose all knowledge of which buffers are relatively hotter.
> Then, when we spill out again, evictions are random.

That's a separate problem, but yes, just because we're not evicting something doesn't mean we can end up with every buffer marked as equally important.

OSes handle this by splitting pages between active and inactive, and maintaining a relative balance between the two (actually a bit more complex because there's a separate inactive/dirty pool).

In our case this could maybe be handled by simply not incrementing counts when there's no eviction... but I'm more a fan of separate polls/clocks, because that means you can do things like a LFU for active and an LRU for inactive.
--
Jim C. Nasby, Data Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net