Re: [HACKERS] Clock with Adaptive Replacement

Jim Nasby writes: > On 2/12/16 9:55 AM, Robert Haas wrote: >> I think it's important to spend time and energy figuring out exactly >> what the problems with our current algorithm are. We know in general >> terms that usage counts tend to converge to either 5 or 0 and >>

Re: [HACKERS] Clock with Adaptive Replacement

On 2/12/16 9:55 AM, Robert Haas wrote: I think it's important to spend time and energy figuring out exactly what the problems with our current algorithm are. We know in general terms that usage counts tend to converge to either 5 or 0 and therefore sometimes evict buffers both at great cost and

Re: [HACKERS] Clock with Adaptive Replacement

Thank you very much for response. I am not sure that CART can significantly improve PostgreSQL performance - I just want to know opinion of community about CAR/CART and other possible alternative to GCLOCK algorithm. Looks like it CAR really provides better cache hit ratio and so at some

Re: [HACKERS] Clock with Adaptive Replacement

On Thu, Feb 11, 2016 at 4:02 PM, Konstantin Knizhnik wrote: > What do you think about improving cache replacement clock-sweep algorithm in > PostgreSQL with adaptive version proposed in this article: > > http://www-cs.stanford.edu/~sbansal/pubs/fast04.pdf > > Are

[HACKERS] Clock with Adaptive Replacement

Hi hackers, What do you think about improving cache replacement clock-sweep algorithm in PostgreSQL with adaptive version proposed in this article: http://www-cs.stanford.edu/~sbansal/pubs/fast04.pdf Are there some well known drawbacks of this approach or it will be interesting to adopt