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