| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
| 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-17 21:41:09 |
| Message-ID: | 5367.1310938869@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tatsuo Ishii | 2011-07-17 21:53:29 | Re: Re: patch review : Add ability to constrain backend temporary file space |
| Previous Message | Tom Lane | 2011-07-17 21:39:02 | Re: Re: patch review : Add ability to constrain backend temporary file space |