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 |/