http://www.slony.info/bugzilla/show_bug.cgi?id=8

In this bug, it is indicated that the number of tuples processed "per
line" or "per submission" seems to be too low in some high-update
scenarios.

http://lists.slony.info/pipermail/slony1-general/2007-November/006931.html

As per Simon Riggs' comments, I'd like to try to solicit discussion as
to how to improve this, pointing particularly towards improving the
default value.

It seems to me that if we set the value somewhat higher, that ought to
be helpful, and I don't see any particular reason NOT to apply this
more or less univerally.

This optimization seems to me to be similar to the way that it is
useful to group multiple updates into one transaction.  In particular,
the BIG improvement, with transaction processing comes from scaling up
from 'tiny transactions' to "somewhat larger."

That is, moving from 1 update per txn to 2 updates per txn leads to a
50% reduction in the number of transactions, and you always get
diminishing returns after that.

If that analogy holds, then I'd expect jumping from 10 statements per
request to 100 would provide ~90% of the improvement possible, and
only have nominal costs in terms of increased memory usage.

Other thoughts???
-- 
(reverse (concatenate 'string "moc.enworbbc" "@" "enworbbc"))
http://linuxdatabases.info/info/x.html
Rules   of the Evil   Overlord  #101. "I  will   not order my  trusted
lieutenant to kill the infant who is  destined to overthrow me -- I'll
do it myself." <http://www.eviloverlord.com/>