Skip site navigation (1) Skip section navigation (2)

Re: Group commit, revised

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Geoghegan <peter(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Group commit, revised
Date: 2012-02-04 05:24:04
Message-ID: CAMkU=1xV75o_5hf7kBPJDahaNn8gmaohKtajaTzm5me69K6iEA@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Mon, Jan 30, 2012 at 6:57 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> 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
>>> 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

In response to

Responses

pgsql-hackers by date

Next:From: Jaime CasanovaDate: 2012-02-04 07:49:31
Subject: Re: Caching for stable expressions with constant arguments v6
Previous:From: Jeff JanesDate: 2012-02-04 05:02:17
Subject: Re: LWLockWaitUntilFree (was: Group commit, revised)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group