Simon Riggs <[EMAIL PROTECTED]> writes: > This design seems to be a clear improvement on the current design. I am > still encouraged that the freelist structures should be subdivided into > many smaller pieces, thereby producing finer grained locks (the earlier > bufferpools proposal).
As I already said, I'm dubious about that idea because of the consequent reduction of cache management efficiency (since any particular page has to fight for survival in a smaller pool). It occurs to me however that we could split up the BufMappingLock in a similar fashion at minimal efficiency penalty. The idea is to replace the global tag->buffer hash table by 2^N separate tables; you determine which one to use based on the low-order N bits of the hash code for the buffer tag, which you always know when accessing these tables. Then give each of these tables its own lock. Essentially this subdivides the buffer tag space into 2^N independent slices. This does not quite work perfectly; the tricky part comes when reclaiming a buffer for use as another page. In the patch as it stands, once we've written out the prior buffer contents we can atomically check for a conflict and reassign the buffer because we need only the one BufMapping lock to do it. But with this idea the old and new associations might belong to different tables. I think the logic would have to be lock old mapping table for buffer; check buffer's not dirty (if so unlock and start over) remove mapping from old table; unlock old table; // at this point we have pin on a completely unassigned buffer lock new mapping table for buffer; check for conflict against someone having already made same entry if found, unlock, put buffer in freelist, use other buffer; insert mapping into new table; unlock new table; This costs us an extra lock/unlock cycle, plus in case of a conflict we end up having unnecessarily evicted a page from cache. But conflicts should be pretty rare, so I think the penalty isn't that great. I don't currently believe that we need this extra complexity, but I thought I'd get the idea into the archives in case it does turn out to be useful later. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]