From: | Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Additional LWLOCK_STATS statistics |
Date: | 2015-09-15 19:51:38 |
Message-ID: | 55F876CA.8020702@redhat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 09/15/2015 03:42 PM, Robert Haas wrote:
> I haven't really, just the email. But it seems like a neat concept.
> So if I understand this correctly:
>
> 74.05% of spin delays are attributable to CLogControLock, 20.01% to
> ProcArrayLock, and 3.39% to XidGenLock. Incredibly, the queue length
> reaches the number of backends (80) for both CLogControlLock and
> XidGenLock, but for ProcArrayLock it "only" reaches a length of 75.
>
74, as the "real" information is above the "call stack". The spin delay
report is filtered on > 0 - so only LWLock's that has any spin delay are
included.
Only the weight report shows all locks.
> This seems to suggest that relieving pressure on CLogControlLock would
> be very beneficial, but I'm not sure what else to make of it.
I have done some runs with Amit's CLogControlLock patch, but currently
it doesn't show any improvements. I'm trying to figure out why.
> It
> would be nice to get a better sense of how *long* we block on various
> locks. It's hard to tell whether some other lock might be have fewer
> blocking events but for a much longer average duration.
>
Yes, that would be interesting.
Best regards,
Jesper
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-09-15 19:57:14 | Re: Multi-tenancy with RLS |
Previous Message | Stephen Frost | 2015-09-15 19:50:46 | Re: RLS open items are vague and unactionable |