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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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