2010/12/8 Tom Lane <tgl@xxxxxxxxxxxxx>: > Robert Haas <robertmhaas@xxxxxxxxx> writes: >> 2010/12/8 Tom Lane <tgl@xxxxxxxxxxxxx>: >>> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
