Re: Just-in-time Background Writer Patch+Test Results - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Just-in-time Background Writer Patch+Test Results
Date
Msg-id 20070909015337.GD6331@alvh.no-ip.org
Whole thread Raw
In response to Re: Just-in-time Background Writer Patch+Test Results  (Greg Smith <gsmith@gregsmith.com>)
List pgsql-hackers
Greg Smith wrote:
> On Sat, 8 Sep 2007, Tom Lane wrote:
>
>> It might be interesting to consider making the delay auto-tune: if you
>> wake up and find nothing (much) to do, sleep longer the next time,
>> conversely shorten the delay when work picks up.  Something for 8.4,
>> though, at this point.
>
> I have a couple of pages of notes on how to tune the delay automatically. 
> The tricky part are applications that go from 0 to full speed with little 
> warning; the first few seconds of the stock market open come to mind.

Maybe have the backends send a signal to bgwriter when they see it
sleeping and are overwhelmed by work.  That way, bgwriter can sleep for
a few seconds, safe in the knowledge that somebody else will wake it up
if needed sooner.  The way backends would detect that bgwriter is
sleeping is that bgwriter would keep an atomic flag in shared memory,
and it gets set only if it's going to sleep for long (so if it's going
to sleep for (say) 100ms or less, it doesn't set the flag, so the
backends won't signal it).  In order to avoid a huge amount of signals
when all backends suddenly start working at the same instant, have the
signal itself be sent only by the first backend that manages to
LWLockConditionalAcquire a lwlock that's only used for that purpose.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


pgsql-hackers by date:

Previous
From: Mark Mielke
Date:
Subject: Re: Hash index todo list item
Next
From: Andrew Dunstan
Date:
Subject: invalidly encoded strings