Re: CommitDelay performance improvement - Mailing list pgsql-hackers

From ncm@zembu.com (Nathan Myers)
Subject Re: CommitDelay performance improvement
Date
Msg-id 20010223132133.P624@store.zembu.com
Whole thread Raw
In response to CommitDelay performance improvement  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: CommitDelay performance improvement  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: CommitDelay performance improvement  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Feb 23, 2001 at 11:32:21AM -0500, Tom Lane wrote:
> A further refinement, still quite cheap to implement since the info is
> in the PROC struct, would be to not count backends that are blocked
> waiting for locks.  These guys are less likely to be ready to commit
> in the next few milliseconds than the guys who are actively running;
> indeed they cannot commit until someone else has committed/aborted to
> release the lock they need.
> 
> 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.

Nathan Myers
ncm@zembu.com


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: beta5 packages ...
Next
From: Matthew
Date:
Subject: RE: beta5 packages ...