On Wed, May 2, 2012 at 11:42 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
