| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
| Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Speed up Clog Access by increasing CLOG buffers |
| Date: | 2017-04-07 17:47:38 |
| Message-ID: | CA+TgmoYKqjN79SpLKWC8kq0gJti1V7MmbG5GZ+arkbGHrKnVow@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Mar 9, 2017 at 5:49 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> However, I just realized that in
> both this case and in the case of group XID clearing, we weren't
> advertising a wait event for the PGSemaphoreLock calls that are part
> of the group locking machinery. I think we should fix that, because a
> quick test shows that can happen fairly often -- not, I think, as
> often as we would have seen LWLock waits without these patches, but
> often enough that you'll want to know. Patch attached.
I've pushed the portion of this that relates to ProcArrayLock. (I
know this hasn't been discussed much, but there doesn't really seem to
be any reason for anybody to object, and looking at just the
LWLock/ProcArrayLock wait events gives a highly misleading answer.)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2017-04-07 17:49:22 | Re: recent deadlock regression test failures |
| Previous Message | Tomas Vondra | 2017-04-07 17:32:19 | Re: Performance issue with postgres9.6 |