Bruce Momjian <[EMAIL PROTECTED]> writes: > If we can't eliminate the global lock, and we reduce its duration?
It'd be a big win even if we could just arrange that ReadBuffer and ReleaseBuffer don't *both* grab the same global lock. Can we logically separate the buffer lookup hashtable from the freelist maintenance code? I am wondering about having two locks, one for each of those areas. In principle I think a fast-path ReadBuffer (one that doesn't need to do I/O because the desired page is in a buffer already) would need to get only a share lock on the lookup table, and never lock the freelist structure at all. ReleaseBuffer would need a write lock on the freelist, but need not touch the lookup table. Only in the case where ReadBuffer has to do I/O, and therefore needs to acquire a free buffer to read the page into, do you need locks on both structures --- and with sufficient care, you might not need to lock them both at the same time, even in that path. To make this work, we would have to recognize that the "freelist" might be out of date --- that is, a page that had been in the freelist because it has zero pins would be left in the freelist by ReadBuffer, and anyone trying to remove it from the freelist for reuse would have to notice that it has positive pin count and realize that it's not really free. But that should be pretty simple. Beyond that we could think about locking just parts of each of these structures (for instance, doesn't ARC really use multiple freelists?) but I think we ought to focus first on that basic division. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])