Re: our buffer replacement strategy is kind of lame
От | Greg Stark |
---|---|
Тема | Re: our buffer replacement strategy is kind of lame |
Дата | |
Msg-id | CAM-w4HMZ7cfMM2udWmramrUKgoY7M4DGYKLTRM0xogA2M=H6wA@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
Re: our buffer replacement strategy is kind of lame Re: our buffer replacement strategy is kind of lame |
Список | pgsql-hackers |
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. It does kind of seem like your numbers indicate we're missing part of the picture though. The idea with the clock sweep algorithm is that you keep approximately 1/nth of the buffers with each of the n values. If we're allowing nearly all the buffers to reach a reference count of 5 then you're right that we've lost any information about which buffers have been referenced most recently. I wonder if we're suppoesd to be doing something like advancing the clock hand each time we increment a reference count as well? -- greg
В списке pgsql-hackers по дате отправления: