Tom Lane <[EMAIL PROTECTED]> writes: > ReadBuffer needs to do a lookup to map the page ID to a buffer ID, > which in principle requires only a shared lock on the page-to-buffer > mapping (embodied in the buf_table hash table). Assuming success, it > also needs to mark the buffer pinned and update the LRU-list position > of the buffer. Marking pinned is certainly a buffer-local change, > so we could imagine splitting up the BufMgrLock like this:
So the only reason you need the global lock is for the LRU updates? This is a well understood problem. I remember it from my Systems class in school. And searching on google finds lecture notes that match my memory that there are other systems generally preferred to LRU precisely because they don't require extensive list management in the critical path. For example these slides: http://www.cs.utexas.edu/users/lorenzo/corsi/cs372/03F/notes/11-20.pdf They describe a few that could be relevant. I recall the clock sweep having been recommended in class as having most of the best properties of LRU with very low cost in the critical path. To use a buffer you only have to set a single local flag indicating the buffer has been used. A separate step advances circularly one buffer at a time clearing the flags. If it finds any buffer that hasn't been used for a complete cycle through the list then it can remove it, either entirely or merely to a second list. -- greg ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org