| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, ik(at)postgresql-consulting(dot)com, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept) |
| Date: | 2014-10-03 21:16:53 |
| Message-ID: | 20141003211653.GW7158@awork2.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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(at)momjian(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2014-10-03 21:17:42 | Re: Promise index tuples for UPSERT |
| Previous Message | Andres Freund | 2014-10-03 21:15:13 | Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept) |