On Tue, Apr 2, 2013 at 9:24 PM, Robert Haas <robertmh...@gmail.com> wrote:
> One thought I had for fiddling with usage_count is to make it grow > additively (x = x + 1) and decay exponentially (x = x >> 1). I'm not > sure the idea is any good, but one problem with the current system is > that it's pretty trivial for a buffer to accumulate five touches, and > after that we lose all memory of what the frequency of access is, so a > pages of varying different levels of "hotness" can all have usage > count 5. This might allow a little more refinement without letting > the time to degrade the usage count get out of control. This is just off the top of my head, but one possible solution could be to quantize the levels of hotness. Specifically, we could categorize buffers based on hotness. All buffers start in level 1 and usage_count 0. Whichever buffer reaches usage_count of 5, and next clock sweep which wants to increment its usage_count(hence taking it above 5) sees that, it promotes the buffer to the next level, and resets its usage_count to 0. Same logic applies for each level. When we decrement usage_count and see that it is zero(for some buffer), if it is in a level > 1, we demote the buffer to the next lower level. If the buffer is in level 1, it is a potential candidate for replacement. This will allow us to have a loose idea about the hotness of a page, without actually storing the usage_count for a buffer. We can still update usage_count without locking, as buffers in high contention which miss an update in their usage_count wont be affected by that missed update, in accordance with all the discussion upthread. Thoughts/Comments? Regards, Atri -- Regards, Atri l'apprenant -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
