| From: | Jim Nasby <jim(at)nasby(dot)net> |
|---|---|
| To: | Atri Sharma <atri(dot)jiit(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | Peter Geoghegan <pg(at)heroku(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Ants Aasma <ants(at)cybertec(dot)at>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Clock sweep not caching enough B-Tree leaf pages? |
| Date: | 2014-04-21 22:38:41 |
| Message-ID: | 53559DF1.8000203@nasby.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2014-04-21 22:41:26 | AXLE Plans for 9.5 and 9.6 |
| Previous Message | Jim Nasby | 2014-04-21 22:26:37 | Re: Clock sweep not caching enough B-Tree leaf pages? |