Kevin Grittner <kgrittn@ymail.com> writes:
> I ran across this function in nbtpage.c:
> /*
> * _bt_relbuf() -- release a locked buffer.
> *
> * Lock and pin (refcount) are both dropped.
> */
> void
> _bt_relbuf(Relation rel, Buffer buf)
> {
> UnlockReleaseBuffer(buf);
> }
> Would anyone object to me removing the first parameter (including,
> obviously, in all references in our code tree)?
-1. It's there first for symmetry with the buffer-acquiring calls,
and second because it's not impossible that the state of the index
might affect what we need to do. (It looks like back in Postgres95
the rel argument was actually needed for functionality, which it
isn't today; but we left it there on those grounds.)
If you have some evidence that this is a live performance issue, then
the thing to do would be to remove this function altogether in favor
of direct calls to UnlockReleaseBuffer, or possibly convert it into a
macro that does that. But I'm not in favor of destroying this level
of abstraction (and creating a significant stumbling block for future
back-patches in nbtree, because there are dozens of calls to this)
without some evidence that we'd be buying something meaningful.
regards, tom lane