Re: _pg_relbuf() Relation paramter

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kevin Grittner <kgrittn(at)ymail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: _pg_relbuf() Relation paramter
Date: 2015-02-04 15:23:41
Message-ID: 3395.1423063421@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Kevin Grittner <kgrittn(at)ymail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-02-04 15:40:49 Re: _pg_relbuf() Relation paramter
Previous Message Kevin Grittner 2015-02-04 15:21:42 Re: _pg_relbuf() Relation paramter