| From: | Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Improving LWLock wait events |
| Date: | 2020-12-23 07:56:32 |
| Message-ID: | CAGRY4nyNYMHPbturyrWOK47hrLYhq68VdzL2wFVXc6L_bL39mg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 23 Dec 2020 at 15:51, Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com>
wrote:
>
> I've struggled with this quite a bit myself.
>
>
By the way, I sent in a patch to enhance the static tracepoints available
for LWLocks. See
https://www.postgresql.org/message-id/CAGRY4nxJo+-HCC2i5H93ttSZ4gZO-FSddCwvkb-qAfQ1zdXd1w@mail.gmail.com
.
It'd benefit significantly from the sort of changes you mentioned in #4.
For most purposes I've been able to just use the raw LWLock* but having a
nice neat (tranche,index) value would be ideal.
The trace patch has helped me identify some excessively long LWLock waits
in tools I work on. I'll share another of the systemtap scripts I used with
it soon.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2020-12-23 08:51:08 | Re: [Patch] Optimize dropping of relation buffers using dlist |
| Previous Message | Craig Ringer | 2020-12-23 07:51:50 | Re: Improving LWLock wait events |