Re: our buffer replacement strategy is kind of lame
Greg Stark <stark@mit.edu>
From: Greg Stark <stark@mit.edu>
To: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-hackers@postgresql.org
Date: 2011-08-13T20:40:15Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Split work of bgwriter between 2 processes: bgwriter and checkpointer.
- 806a2aee3791 9.2.0 cited
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