On Mon, Jan 30, 2012 at 6:57 AM, Heikki Linnakangas
> On 27.01.2012 15:38, Robert Haas wrote:
>> On Fri, Jan 27, 2012 at 8:35 AM, Heikki Linnakangas
>> <heikki(dot)linnakangas(at)enterprisedb(dot)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
>>> 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.
In response to
pgsql-hackers by date
|Next:||From: Jaime Casanova||Date: 2012-02-04 07:49:31|
|Subject: Re: Caching for stable expressions with constant arguments v6|
|Previous:||From: Jeff Janes||Date: 2012-02-04 05:02:17|
|Subject: Re: LWLockWaitUntilFree (was: Group commit, revised)|