2012/06/26 6:44, Josh Berkus 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.
Thanks. I will submit the patch to the CommitFest page with some fixes
to be able to work with the latest PostgreSQL on Git.
> I will remark that it would be far more useful to me if we could also
> track lwlocks per session. Overall counts are somewhat useful, but more
> granular counts are even more useful. What period of time does the
> table cover? Since last reset?
Yes. it has not yet been implemented yet since this code is just a PoC
one, but it is another design issue which needs to be discussed.
To implement it, a new array can be added in the local process memory
to hold lwlock statistics, and update counters both in the shared
memory and the local process memory at once. Then, the session can
retrieve 'per-session' statistics from the local process memory
via some dedicated function.
Does it make sense? Any comments?
Regards,
--
Satoshi Nagayasu <snaga@uptime.jp>
Uptime Technologies, LLC. http://www.uptime.jp
