On Wed, Sep 16, 2015 at 1:21 AM, Jesper Pedersen <jesper.peder...@redhat.com> wrote: > > 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. >
Thanks for testing the patch. I think even if you are not getting improvement, feel free to report about it with details. I can also look into it that why it is not showing improvement. Two important points to care about while testing that patch are that data should fit in shared_buffers and synchronous_commit should be on, for other kind of workloads it might or might not give much benefit. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
