On Sat, Aug 13, 2011 at 11:14 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Sat, Aug 13, 2011 at 4:40 PM, Greg Stark <st...@mit.edu> wrote: >> On Sat, Aug 13, 2011 at 8:52 PM, Robert Haas <robertmh...@gmail.com> wrote: >>> and possibly we ought to put them all in a >>> linked list so that the next guy who needs a buffer can just pop one >> >> The whole point of the clock sweep algorithm is to approximate an LRU >> without needing to maintain a linked list. The problem with a linked >> list is that you need to serialize access to it so every time you >> reference a buffer you need to wait on a lock for the list so you can >> move that buffer around in the list. > > Right, but the same doesn't apply to what I'm talking about. You just > put each guy into the linked list when his reference count goes down > to 0. When you want to allocate a buffer, you pop somebody off. If > his reference count is still 0, you forget about him and pop the next > guy, and keep going until you find a suitable victim. > > The problem with just running the clock sweep every time you need a > victim buffer is that you may have to pass over a large number of > unevictable buffers before you find someone you can actually kick out. > That's work that should really be getting done in the background, not > at the absolute last moment when we discover, hey, we need a buffer.
I think Greg is right here. Those suggested changes just bring back the LRU. If you keep a separate list then you need to serialize access to it. usage_count == 0 and "unevictable" are dynamic states, so if the bgwriter sees those states they can change before anyone uses the buffer. The only state which is unchangeable is a recently filled block, such as from a COPY, which is why I originally suggested a filled-block-list - though I don't think we need it now because of the buffer cycle strategy. -- Simon Riggs 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
