Re: Reducing overhead of frequent table locks

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, May 13, 2011 at 11:05 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
>> Incidentally, I used the term "local lock" because I assumed fast-path locks
>> would still go through the lock manager far enough to populate the local lock
>> table. But there may be no reason to do so.

> Oh, good point. I think we probably WOULD need to update the local
> lock lock hash table.

I haven't read this thread closely, but the general behavior of the
backend assumes that it's very very cheap to re-acquire a lock that's
already held by the current transaction. It's probably worth
maintaining a local counter just so you can keep that being true, even
if there were no other need for it. (Since I've not read the thread,
I'll refrain from asking how you're gonna clean up at transaction end
if there's no local memory of what locks you hold.)

regards, tom lane