On Tue, Apr 2, 2013 at 11:32 AM, Merlin Moncure <mmonc...@gmail.com> wrote: > That's a very fair point, although not being able to evict pinned > buffers is a highly mitigating aspect. Also CLOG is a different beast > entirely -- it's much more dense (2 bits!) vs a tuple so a single page > can a lot of high priority things. But you could be right anyways. > > Given that, I wouldn't feel very comfortable with forced eviction > without knowing for sure high priority buffers were immune from that. > Your nailing idea is maybe the ideal solution. Messing around with > the usage_count mechanic is tempting (like raising the cap and making > the sweeper more aggressive as it iterates), but probably really > difficult to get right, and, hopefully, ultimately moot.
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. But, having said that, I still think the best idea is what Andres proposed, which pretty much matches my own thoughts: the bgwriter needs to populate the free list, so that buffer allocations don't have to wait for linear scans of the buffer array. That's just plain too slow. -- 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
