Re: Clock sweep not caching enough B-Tree leaf pages? - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: Clock sweep not caching enough B-Tree leaf pages?
Date
Msg-id 535ED05B.3030006@nasby.net
Whole thread Raw
In response to Re: Clock sweep not caching enough B-Tree leaf pages?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Clock sweep not caching enough B-Tree leaf pages?  (Kevin Grittner <kgrittn@ymail.com>)
List pgsql-hackers
On 4/28/14, 8:04 AM, Robert Haas wrote:
> On Mon, Apr 21, 2014 at 6:38 PM, Jim Nasby <jim@nasby.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
buffermarked as equally important.
 

OSes handle this by splitting pages between active and inactive, and maintaining a relative balance between the two
(actuallya 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
fanof 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@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net



pgsql-hackers by date:

Previous
From: Kohei KaiGai
Date:
Subject: Re: Custom Scan APIs (Re: Custom Plan node)
Next
From: Peter Eisentraut
Date:
Subject: Re: Problem with displaying "wide" tables in psql