Re: CommitDelay performance improvement - Mailing list pgsql-hackers

From Tom Lane
Subject Re: CommitDelay performance improvement
Date
Msg-id 11005.982994837@sss.pgh.pa.us
Whole thread Raw
In response to Re: CommitDelay performance improvement  (ncm@zembu.com (Nathan Myers))
Responses Re: CommitDelay performance improvement  (ncm@zembu.com (Nathan Myers))
List pgsql-hackers
ncm@zembu.com (Nathan Myers) writes:
> I see, I had it backwards: N=0 corresponds to "always delay", and 
> N=infinity (~0) is "never delay", or what you call zero delay.  N=1 is 
> not interesting.  N=M/2 or N=sqrt(M) or N=log(M) might be interesting, 
> where M is the number of backends, or the number of backends with begun 
> transactions, or something.  N=10 would be conservative (and maybe 
> pointless) just because it would hardly ever trigger a delay.

Why is N=1 not interesting?  That requires at least one other backend
to be in a transaction before you'll delay.  That would seem to be
the minimum useful value --- N=0 (always delay) seems clearly to be
too stupid to be useful.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Christopher Sawtell
Date:
Subject: Re: [GENERAL] problem while compiling user c functions in 7.1beta4
Next
From: Bruce Momjian
Date:
Subject: Re: CommitDelay performance improvement