Re: Performance under contention - Mailing list pgsql-performance

From Tom Lane
Subject Re: Performance under contention
Date
Msg-id 21911.1291845739@sss.pgh.pa.us
Whole thread Raw
In response to Re: Performance under contention  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Performance under contention  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-performance
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.

            regards, tom lane

pgsql-performance by date:

Previous
From: Robert Haas
Date:
Subject: Re: Performance under contention
Next
From: "Benjamin Krajmalnik"
Date:
Subject: Hardware recommendations