On Thu, May 31, 2012 at 3:25 PM, Merlin Moncure <mmonc...@gmail.com> wrote: > Hm, couple questions: how do you determine if/when to un-nail a > buffer, and who makes that decision (bgwriter?)
Well, I think some experimentation might be required, but my first thought is to tie it into buffer eviction. If we record a pin in some side array in lieu of acquiring the buffer header spinlock, then we're not bumping the usage count. So perhaps what we might do is - when we first nail the buffer, we set it's usage count to something much higher than what's normally allowed, like say 50. When it gets down to 0 and somebody tries to evict it, we scan the per-backend arrays and count the number of pins we find there, and set the usage count to 5 * that number. The details could be completely wrong here. The point is that I think every so often we can just reconsider whether the buffer is still worthy of being nailed. Exactly how often we should reconsider it seems like an empirical question. > Is there a limit to > how many buffers you are allowed to nail? Probably not. The system had better be designed so that the threshold for nailing a buffer is pretty high. It should be exceedingly unlikely for more than a small percentage of buffers to meet the criteria; if it happens, then there's probably a good reason. > It seems like a much > stronger idea, but one downside I see vs the 'pin for longer idea' i > was kicking around was how to deal stale nailed buffers and keeping > them from uncontrollably growing so that you have to either stop > nailing or forcibly evicting them. I think we're really talking about variants on the same theme. My idea is basically "pin forever", which is taking "longer" to its logical extreme, but even if it were something short of forever I think you'd still need some way to flush the stale pins. Otherwise, vacuum can get stuck, etc. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
