On Wed, 2008-02-06 at 13:55 -0500, Tom Lane wrote:
> Gregory Stark <stark@enterprisedb.com> writes:
> > "Staale Smedseng" <Staale.Smedseng@Sun.COM> 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
