2012/06/26 7:04, Kevin Grittner wrote:
Josh Berkus<j...@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 <sn...@uptime.jp>
Uptime Technologies, LLC. http://www.uptime.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
