2010/12/8 Tom Lane <tgl@sss.pgh.pa.us>:
> Robert Haas <robertmhaas@gmail.com> writes:
>> 2010/12/8 Tom Lane <tgl@sss.pgh.pa.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
