Re: Reduced power consumption in WAL Writer process - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Reduced power consumption in WAL Writer process
Date
Msg-id CA+U5nMKkzyffenhm2M7s5BeggOHWYJiA9dS96Shg9Jq===8sqw@mail.gmail.com
Whole thread Raw
In response to Re: Reduced power consumption in WAL Writer process  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Reduced power consumption in WAL Writer process
List pgsql-hackers
On Fri, Jul 15, 2011 at 6:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Jul 15, 2011, at 8:55 AM, Simon Riggs <simon@2ndQuadrant.com> wrote:
>>> The only difference is how bulk write operations are handled. As long
>>> as we wake WALWriter before wal_buffers fills then we'll be good.
>>> Wakeup once per wal buffer is too much. I agree we should measure this
>>> to check how frequently wakeups are required for bulk ops.
>
>> Yeah. The trick is to get the wake-ups to be frequent enough without
>> adding too much latency to the backends that have to perform them. Off-hand,
>> I don't  have a good feeling for how hard that will be.
>
> 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.

Yes, I was trying to go too simple.

I think we need to put the calculation and SetLatch() after we release
WALInsertLock, so as to avoid adding contention.

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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Add temp_file_limit GUC parameter to constrain temporary file sp
Next
From: Tom Lane
Date:
Subject: Re: Re: patch review : Add ability to constrain backend temporary file space