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

Jim C. Nasby <jim@nasby.net>

From: Jim Nasby <jim@nasby.net>
To: Atri Sharma <atri.jiit@gmail.com>, Bruce Momjian <bruce@momjian.us>
Cc: Peter Geoghegan <pg@heroku.com>, Greg Stark <stark@mit.edu>, Ants Aasma <ants@cybertec.at>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2014-04-21T22:38:41Z
Lists: pgsql-hackers
On 4/18/14, 2:51 PM, Atri Sharma 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*.

> One thing that I discussed with Merlin offline and am now concerned about is how will the actual eviction work. We cannot traverse the entire list and then find all the buffers with refcount 0 and then do another traversal to find the oldest one.

This is why OSes use multiple page pools. If we're going to use a clock sweep at all I think we need to use the same.

Every time we discuss this stuff it feels like we're completely reinventing the wheel that was solved by OSes years ago. :(
-- 
Jim C. Nasby, Data Architect                       jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net


Commits

  1. Replace the BufMgrLock with separate locks on the lookup hashtable and