On 2013-04-02 11:54:32 -0400, Robert Haas wrote: > 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.
That way the usagecount should go down far more slowly which essentially makes it more granular. And I think fiddling on that level before we have a more sensible buffer acquiration implementation is pretty premature since that will change too much. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers