Re: CommitDelay performance improvement

At 00:42 25/02/01 -0800, Nathan Myers wrote:
>
>The only really bad performers were (0), (10k,1), (100k,20).  The best
>were (30k,1) and (30k,10), although (30k,5) also did well except at 40.
>Why would 30k be a magic delay, regardless of siblings?  What happened
>at 40?
>

I had assumed that 40 was one of the glitches - it would be good if Tom (or
someone else) could rerun the suite, to see if we see the same dip.

I agree that 30k looks like the magic delay, and probably 30/5 would be a
good conservative choice. But now I think about the choice of number, I
think it must vary with the speed of the machine and length of the
transactions; at 20tps, each TX is completing in around 50ms. Probably the
delay needs to be set at a value related to the average TX duration, and
since that is not really a known figure, perhaps we should go with 30% of
TX duration, with a max of 100k. 

Alternatively, can PG monitor the commits/second, then set the delay to
reflect half of the average TX time (or 100ms, whichever is smaller)? Is
this too baroque?

----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|                                |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/