Re: Reduced power consumption in WAL Writer process

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Peter Geoghegan <peter(at)2ndquadrant(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Reduced power consumption in WAL Writer process
Date: 2011-07-18 06:32:13
Message-ID: CA+U5nMJ335JOYxaG=JgDGaamc1d_KFg9-mWLmW-7r16XVxtAaQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jul 17, 2011 at 10:41 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
>> On Fri, Jul 15, 2011 at 6:33 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> I'd say send the signal when wal buffers are more than X% full (maybe
>>> half).  The suggestion to send it when wrapping around at the end of the
>>> array is not quite right, because that's an arbitrary condition that's
>>> not related to how much work there is for the walwriter to do.  It
>>> should be cheap to check for this while advancing to a new wal buffer.
>
>> I think we need to put the calculation and SetLatch() after we release
>> WALInsertLock, so as to avoid adding contention.
>
> Yeah, I agree with putting the actual SetLatch call after we release the
> lock ... but doesn't the calculation need to be done while we're still
> holding it?  Otherwise it'd be using potentially-inconsistent values.

The calculation is just a heurustic, so doesn't need to be exactly
accurate. We need the latest values derived while holding the lock,
but we don't need to ensure they change while we make the calc.

The calc needs to say "if we are the ones who make the array more than
half full, then wake up the WALWriter". It might already be awake, it
might be already be more than half full or it might even be less than
half full now - none of those cases are very important.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2011-07-18 07:14:38 Re: Single pass vacuum - take 1
Previous Message Robert Haas 2011-07-18 05:29:37 Re: storing TZ along timestamps