Re: pg_stat_lwlocks view - lwlocks statistics - Mailing list pgsql-hackers

From Satoshi Nagayasu
Subject Re: pg_stat_lwlocks view - lwlocks statistics
Date
Msg-id 4FE92813.5030308@uptime.jp
Whole thread Raw
In response to pg_stat_lwlocks view - lwlocks statistics  (Satoshi Nagayasu <snaga@uptime.jp>)
List pgsql-hackers
2012/06/26 7:04, Kevin Grittner wrote:
> Josh Berkus<josh@agliodbs.com>  wrote:
>> On 6/25/12 1:29 PM, Satoshi Nagayasu wrote:
>>> (1) Performance
>>>
>>>    I've measured LWLock performance both with and without the
>>>    patch, and confirmed that this patch does not affect the LWLock
>>>    perfomance at all.
>>
>> This would be my main concern with this patch; it's hard for me to
>> imagine that it has no performance impact *at all*, since
>> trace_lwlocks has quite a noticable one in my experience.
>> However, the answer to that is to submit the patch and let people
>> test.
>
> I think overhead is going to depend quite a bit on the
> gettimeofday() implementation, since that is called twice per lock
> wait.

Yes.
It's one of my concerns, and what I actually want hackers to test.

> It looked to me like there was nothing to prevent concurrent updates
> of the counts while gathering the accumulated values for display.
> Won't this be a problem on 32-bit builds?

Actually, I'd like to know how I can improve my code in a 32bit box.

However, unfortunately I don't have any 32bit (physical) box now,
so I want someone to test it if it needs to be tested.

> Please add this to the Open COmmitFest for a proper review:
>
> https://commitfest.postgresql.org/action/commitfest_view/open

Will submit soon. Thanks.

>
> -Kevin
>

Regards,
-- 
Satoshi Nagayasu <snaga@uptime.jp>
Uptime Technologies, LLC. http://www.uptime.jp


pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: patch: avoid heavyweight locking on hash metapage
Next
From: Amit Kapila
Date:
Subject: Re: WAL format changes