Re: Why are we waiting?

Staale Smedseng <Staale(dot)Smedseng(at)Sun(dot)COM> writes:
> Good catch. We've checked the DTrace scripts against the respective
> versions of lwlock.h, and the FirstLockMgrLock is off (this is actually
> the results for FirstBufMappingLock).

> However, this is the last lock in the enum that we trace, the other
> lower-numbered lock enums were correctly mapped. (In particular the
> ProcArrayLock which we've been puzzled by.)

Hmm, do you mean that you're just neglecting to collect any stats about
all the dynamically assigned locks? That doesn't seem like it's going
to offer a very good view of what's going on. I think the most useful
stats would include aggregate wait data for all the lockmgr locks,
all the bufmapping locks, all the buffer content locks, and all the
buffer I/O locks. We'd like to think that contention for those would
be low because of the partitioning ... but the point of measuring is
to find out, not just hope.

regards, tom lane