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 [EMAIL PROTECTED]
- [HACKERS] CommitDelay performance improvement Tom Lane
- Re: [HACKERS] CommitDelay performance improvement Bruce Momjian
- Re: [HACKERS] CommitDelay performance improvement Tom Lane
- Re: [HACKERS] CommitDelay performance improveme... Bruce Momjian
- Re: [HACKERS] CommitDelay performance impro... Tom Lane
- Re: [HACKERS] CommitDelay performance ... Bruce Momjian
- Re: [HACKERS] CommitDelay performance improvement Nathan Myers
- Re: [HACKERS] CommitDelay performance improvement Bruce Momjian
- Re: [HACKERS] CommitDelay performance improvement Tom Lane
- Re: [HACKERS] CommitDelay performance improveme... Bruce Momjian
- Re: [HACKERS] CommitDelay performance impro... Tom Lane
- Re: [HACKERS] CommitDelay performance ... Bruce Momjian
- Re: [HACKERS] CommitDelay performa... Tom Lane
- Re: [HACKERS] CommitDelay perf... Bruce Momjian
- Re: [HACKERS] CommitDelay perf... Tom Lane
- Re: [HACKERS] CommitDelay perf... Bruce Momjian
- Re: [HACKERS] CommitDelay perf... Philip Warner