Re: our buffer replacement strategy is kind of lame
| От | Simon Riggs |
|---|---|
| Тема | Re: our buffer replacement strategy is kind of lame |
| Дата | |
| Msg-id | CA+U5nM+jWkoTcgHDBduJsnt2an=h4MuWHEYpGRKdHY9N3TeqQQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: our buffer replacement strategy is kind of lame (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: our buffer replacement strategy is kind of lame
|
| Список | pgsql-hackers |
On Sat, Aug 13, 2011 at 11:14 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Sat, Aug 13, 2011 at 4:40 PM, Greg Stark <stark@mit.edu> wrote: >> On Sat, Aug 13, 2011 at 8:52 PM, Robert Haas <robertmhaas@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
В списке pgsql-hackers по дате отправления: