On Wed, Apr 16, 2014 at 4:22 AM, Peter Geoghegan <p...@heroku.com> wrote: > > I don't want to dismiss what you're saying about heating and cooling > being unrelated, but I don't find the conclusion that not everything > can be hot obvious. Maybe "heat" should be relative rather than > absolute, and maybe that's actually what you meant. There is surely > some workload where buffer access actually is perfectly uniform, and > what do you do there? What "temperature" are those buffers?
In that case, hotness, or retention priority, should be relative to re-population cost. IE: whether it's likely to still be in the OS cache or not, whether it's dirty or not, etc. > It occurs to me that within the prototype patch, even though > usage_count is incremented in a vastly slower fashion (in a wall time > sense), clock sweep doesn't take advantage of that. I should probably > investigate having clock sweep become more aggressive in decrementing > in response to realizing that it won't get some buffer's usage_count > down to zero on the next revolution either. There are certainly > problems with that, but they might be fixable. Within the patch, in > order for it to be possible for the usage_count to be incremented in > the interim, an average of 1.5 seconds must pass, so if clock sweep > were to anticipate another no-set-to-zero revolution, it seems pretty > likely that it would be exactly right, or if not then close enough, > since it can only really fail to correct for some buffers getting > incremented once more in the interim. Conceptually, it would be like > multiple logical revolutions were merged into one actual one, > sufficient to have the next revolution find a victim buffer. Why use time at all? Why not synchronize usage bumpability to clock sweeps? I'd use a simple bit that the clock sweep clears, and the users set. Only one increase per sweep. Or maybe use a decreasing loop count instead of a bit. In any case, measuring "time" in terms of clock sweeps sounds like a better proposition. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
