Re: Reducing contention for the LockMgrLock - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Reducing contention for the LockMgrLock
Date
Msg-id 1134035836.2906.1070.camel@localhost.localdomain
Whole thread Raw
In response to Re: Reducing contention for the LockMgrLock  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Reducing contention for the LockMgrLock  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, 2005-12-07 at 22:53 -0500, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > My view would be that the LockMgrLock is not relevant for all workloads,
> > but I want even more to be able to discuss whether it is, or is not, on
> > an accepted basis before discussions begin.
> 
> Certainly.  I showed the evidence ...

The output you gave wasn't anything I recognize in the code. Assuming
its not already there, please can you share code you are using to find
the evidence, even if its just privately in some form?

You're looking at the number of spins to acquire each lock? Or some
other measure of wait time on a lock?

I want to be in a position to run tests and then share the output with
the project in an agreed form, then quickly move to action. You're right
to put the burden of proof onto test results; I want to agree the
measurements before we test.

Manfred's earlier patch provides very clear output for observing
contention, including full summaries. Could we commit that, so we can
all use this for analysis? Updated with the wait info.

Best Regards, Simon Riggs






pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Reducing contention for the LockMgrLock
Next
From: Hannu Krosing
Date:
Subject: Re: Reducing relation locking overhead