Re: Performance under contention

2010/12/8 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> 2010/12/8 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>>> Now, it's possible that you could avoid *ever* needing to search for a
>>> specific PROCLOCK, in which case eliminating the hash calculation
>>> overhead might be worth it.
>
>> That seems like it might be feasible.  The backend that holds the lock
>> ought to be able to find out whether there's a PROCLOCK by looking at
>> the LOCALLOCK table, and the LOCALLOCK has a pointer to the PROCLOCK.
>
> Hm, that is a real good point.  Those shared memory data structures
> predate the invention of the local lock tables, and I don't think we
> looked real hard at whether we should rethink the fundamental
> representation in shared memory given the additional local state.
> The issue though is whether any other processes ever need to look
> at a proc's PROCLOCKs.  I think at least deadlock detection does.

Sure, but it doesn't use the hash table to do it. All the PROCLOCKs
for any given LOCK are in a linked list; we just walk it.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company