Re: CommitDelay performance improvement - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: CommitDelay performance improvement
Date
Msg-id 200102232226.RAA01927@candle.pha.pa.us
Whole thread Raw
In response to Re: CommitDelay performance improvement  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: CommitDelay performance improvement  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> ncm@zembu.com (Nathan Myers) writes:
> >> Comments?  What should the threshold N be ... or do we need to make
> >> that a tunable parameter?
> 
> > Once you make it tuneable, you're stuck with it.  You can always add
> > a knob later, after somebody discovers a real need.
> 
> If we had a good idea what the default level should be, I'd be willing
> to go without a knob.  I'm thinking of a default of about 5 (ie, at
> least 5 other active backends to trigger a commit delay) ... but I'm not
> so confident of that that I think it needn't be tunable.  It's really
> dependent on your average and peak transaction lengths, and that's
> going to vary across installations, so unless we want to try to make it
> self-adjusting, a knob seems like a good idea.
> 
> A self-adjusting delay might well be a great idea, BTW, but I'm trying
> to be conservative about how much complexity we should add right now.

OH, so you are saying N backends should have dirtied buffers before
doing the delay?  Hmm, that seems almost untunable to me.

Let's suppose we decide to sleep.  When we wake up, can we know that
someone else has fsync'ed for us?  And if they have, should we be more
likely to fsync() in the future?

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: CommitDelay performance improvement
Next
From: Vince Vielhaber
Date:
Subject: Re: regression test form