On Wed, 2008-02-06 at 13:55 -0500, Tom Lane wrote: > Gregory Stark <[EMAIL PROTECTED]> writes: > > "Staale Smedseng" <[EMAIL PROTECTED]> writes: > >> Also, an interesting observation is that the hot locks seem to have > >> changed from v8.2 to v8.3, making the ProcArrayLock more contended. See > >> the following outputs: > >> > >> PostgreSQL 8.2 (32-bit): > >> ... > >> PostgreSQL 8.3 (64-bit): > >> ... > > > I'm not sure 32-bit and 64-bit cases are going to be directly comparable. We > > could have a problem with cache line aliasing on only one or the other for > > example. > > Yeah, I find these numbers highly dubious. AFAIR we didn't do anything > that would have reduced CLogControlLock contention, and we definitely > did work to reduce ProcArrayLock contention, so the claimed results seem > directly opposite to expectation. I am wondering if the waits are being > attributed to the right locks --- I remember such an error in a previous > set of dtrace results, and some of the other details such as claiming > shared lock delays but no exclusive lock delays for FirstLockMgrLock > seem less than credible as well.
There were only 2 lock delays for FirstLockMgrLock in SHARED mode, so it seems believable that there were 0 lock delays in EXCLUSIVE mode. I assumed that Staale is running with clog buffers tweaked? Can you confirm Staale? -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
