[9.5] possible fast path for pinning a page multiple times

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: [9.5] possible fast path for pinning a page multiple times
Date: 2014-05-25 15:54:06
Message-ID: 1401033246.24650.44.camel@jeff-desktop
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.1030700@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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-05-25 16:01:34 Re: assertion in 9.4 with wal_level=logical
Previous Message Andres Freund 2014-05-25 15:53:45 Re: Could not finish anti-wraparound VACUUM when stop limit is reached