Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept) - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept)
Date
Msg-id 20141003211653.GW7158@awork2.anarazel.de
Whole thread Raw
In response to Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept)  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 2014-10-03 11:51:46 -0400, Robert Haas wrote:
> On Fri, Oct 3, 2014 at 11:33 AM, Bruce Momjian <bruce@momjian.us> wrote:
> > I am assuming almost no one cares about the number of locks, but rather
> > they care about cummulative lock durations.
> >
> > I am having trouble seeing any other option that has such a good
> > cost/benefit profile.
> 
> I do think that the instrumentation data gathered by LWLOCK_STATS is
> useful - very useful.
> 
> But it does have significant overhead.

Have you ever analyzed where that overhead is with the current code?

I do wonder if having a per backend array in shmem indexed by the lockid
(inside its tranche) wouldn't be quite doable for the smaller tranches.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Trailing comma support in SELECT statements
Next
From: Peter Geoghegan
Date:
Subject: Re: Promise index tuples for UPSERT