From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | 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-15 17:13:19 |
Message-ID: | 4B6186BB-5B3E-4416-BE0A-52F424018E4B@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Jul 15, 2011, at 8:55 AM, Simon Riggs <simon(at)2ndQuadrant(dot)com> wrote:
> On Fri, Jul 15, 2011 at 2:29 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
>> If the primary goal here is to reduce power consumption, another option
>> would be to keep the regular wake-ups most of the time but have some
>> mechanism for putting the process to sleep until wakened when no activity
>> happens for a certain period of time - say, 10 cycles. I'm not at all sure
>> that's better, but it would be less of a change to the existing behavior.
>
> Now we have them, latches seem the best approach because they (mostly)
> avoid heuristics.
That's my feeling as well.
> This proposal works same or better for async transactions.
Right. I would say probably better. The potential for a reduction in latency here is very appealing.
> 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.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-07-15 17:33:10 | Re: Reduced power consumption in WAL Writer process |
Previous Message | Bruce Momjian | 2011-07-15 17:12:42 | Re: Need help understanding pg_locks |