Context: A patch from a while ago was rejected:
http://www.postgresql.org/message-id/1369886097.23418.0.camel@jdavis Most of the objection seemed to be that extra page pins might happen in some circumstances, such as this one mentioned by Heikki: http://www.postgresql.org/message-id/50fd11c5.1030...@vmware.com That was a single-threaded case, but did represent additional pins being acquired, which could add up to contention over the BufMappingPartitionLock if there is other traffic on that lock partition. Idea: Let's say we have a routine PinBufferTag, that's like PinBuffer but it takes an additional BufferTag argument. When it locks the buffer header, it would also compare the argument to the buffer's tag, and if they don't match, return a status indicating that it's the wrong buffer and don't pin it. In other words, it pins the buffer only if it's the right one. Then, we can just have a backend-local cache that maps BufferTag to buffer ID. If it's missing an entry, or if the entry is wrong, then it just proceeds with the normal BufferAlloc path. But if the cache holds the right value, then we completely bypass the BufMappingPartitionLock while getting the pin. Before I do too much performance testing of this, is it a correct approach? It seems too easy. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
