On Mon, Jan 30, 2012 at 6:57 AM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > On 27.01.2012 15:38, Robert Haas wrote: >> >> On Fri, Jan 27, 2012 at 8:35 AM, Heikki Linnakangas >> <heikki.linnakan...@enterprisedb.com> wrote: >>> >>> Yeah, we have to be careful with any overhead in there, it can be a hot >>> spot. I wouldn't expect any measurable difference from the above, though. >>> Could I ask you to rerun the pgbench tests you did recently with this >>> patch? >>> Or can you think of a better test for this? >> >> >> I can't do so immediately, because I'm waiting for Nate Boley to tell >> me I can go ahead and start testing on that machine again. But I will >> do it once I get the word. > > > I committed this. I ran pgbench test on an 8-core box and didn't see any > slowdown. It would still be good if you get a chance to rerun the bigger > test, but I feel confident that there's no measurable slowdown.
Is it safe to assume that, under "#ifdef LWLOCK_STATS", a call to LWLockAcquire will always precede any calls to LWLockWaitUntilFree when a new process is started, to calloc the stats assays? I guess it is right now, because the only user is WALWrite, which would never be acquired before WALInsert is at least once. But this doesn't seem very future proof. I guess the same complain could be logged against LWLockConditionalAcquire. Since people wouldn't be expected to define LWLOCK_STATS on production builds, perhaps this issue is ignorable. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
