On Wed, May 2, 2012 at 11:42 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> ... It seems unlikely to cause any real
>> problem if WAL writer takes a couple seconds to get with the program
>> after a long period of inactivity; note that an async commit will kick
>> it anyway, and a sync commit will probably half to flush WAL whether
>> the WAL writer wakes up or not.
>
> That's a good point. What about only kicking the WAL writer in code
> paths where a backend found itself having to write/flush WAL for itself?
> The added overhead is very surely negligible in such a situation.
Yeah, I think that would make sense, though I'd probably still argue
for a hibernation period not quite so long as ten seconds. Actually,
what I'd really like is for this to be adaptive: if we find that
there's no WAL to write, increase the time until the next wakeup by 10
ms until we hit the maximum of, say, 3 seconds. If we find that there
is WAL to write, cut the time until the next wakeup in half until we
hit a minimum of, say, 20ms. And, if we're forced to write/flush WAL
ourselves, or we async commit, kick the WAL writer in the pants and
wake him up right away. That way we're willing to get
super-aggressive when needed, but we don't stay there very long once
the pounding ends. Also, we avoid having a hard "cut" between regular
sleeps and deep hibernation; instead, we kind of gradually drift off.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
