Skip site navigation (1) Skip section navigation (2)

Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)
Date: 2010-08-28 21:00:31
Message-ID: 4C7978EF.9070507@2ndquadrant.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:
> Greg Smith <greg(at)2ndquadrant(dot)com> writes:
>   
>> ...  The only clear case where this is 
>> always a win is when the system it totally idle.
>>     
> If you'll climb down off that horse for a moment: yeah, the idle case is
> *exactly* what they're complaining about.

I wasn't on a horse here--I saw the specific case they must be most 
annoyed with.  If it's possible to turn this around into a "push" model 
instead of how it works now, without tanking so that performance (and 
maybe even power use!) suffers for the worst or even average case, that 
refactoring could end up outperforming the current model.  I'd like the 
background writer to never go to sleep at all really if enough works 
come in to keep it always busy, and I think that might fall out nicely 
as a result of aiming for the other end--making it sleeper deeper when 
it's not needed.

Just pointing out the very specific place where I suspect that will go 
wrong if it's not done carefully is the fsync absorption, because it's 
already broken enough that we're reworking it here.  PostgreSQL already 
ship a bad enough default configuration to decide yet another spot 
should be yielded to somebody else's priorities, unless that actually 
meets performance goals.  I think I can quantify what those should be 
with a test case for this part.

> I see this as just another facet of the argument about whether it's okay
> to have default settings that try to take over the entire machine.
>   

Mostly agreed here.  So long as the result is automatic enough to not 
introduce yet another GUC set to the wrong thing for busy systems by 
default, this could turn out great.  The list of things you must change 
to get the database to work right for serious work is already far too 
long, and I dread the thought of putting yet another on there just for 
the sake of lower power use.  Another part of the plan for world 
domination is that Oracle DBAs install the database for a test and say 
"wow, that wasn't nearly as complicated as I'm used to and it performs 
well, that was nice".  That those people matter too is all I'm saying.  
I could easily file a bug from their perspective saying "Background 
writer is a lazy SOB in default config" that would be no less valid than 
the one being discussed here.

-- 
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com   www.2ndQuadrant.us


In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-08-28 23:43:54
Subject: Re: [GENERAL] 3rd time is a charm.....right sibling is not next child crash.
Previous:From: Tom LaneDate: 2010-08-28 20:11:10
Subject: Re: 3rd time is a charm.....right sibling is not next child crash.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group