Re: Why are we waiting?

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