Update of /home/cvsd/slony1/slony1-engine/doc/adminguide
In directory main.slony.info:/tmp/cvs-serv22846

Modified Files:
	intro.sgml 
Log Message:
Revise text about the growth of communications costs to temper wording
that has tended to lead to people saying wild things about Slony-I 
performance.


Index: intro.sgml
===================================================================
RCS file: /home/cvsd/slony1/slony1-engine/doc/adminguide/intro.sgml,v
retrieving revision 1.29
retrieving revision 1.30
diff -C 2 -d -r1.29 -r1.30
*** intro.sgml	25 Feb 2008 15:37:58 -0000	1.29
--- intro.sgml	9 Jul 2010 18:40:13 -0000	1.30
***************
*** 291,296 ****
  <listitem><para> It is necessary to have <xref
  linkend="table.sl-listen"> entries allowing connection from each node
! to every other node.  Most will normally not need to be very heavily,
! but it still means that there needs to be n(n-1) paths.
  </para></listitem>
  
--- 291,296 ----
  <listitem><para> It is necessary to have <xref
  linkend="table.sl-listen"> entries allowing connection from each node
! to every other node.  Most will normally not need to be used terribly
! heavily, but it still means that there needs to be n(n-1) paths.
  </para></listitem>
  
***************
*** 304,308 ****
  n(n/2) times.  Again, this points to a quadratic growth in
  communications costs as the number of nodes
! increases.</para></listitem>
  
  </itemizedlist></para>
--- 304,333 ----
  n(n/2) times.  Again, this points to a quadratic growth in
  communications costs as the number of nodes
! increases.  </para>
! 
! <para> Mind you, the work will be divided across n nodes, so while the
! <emphasis>total</emphasis> amount of work goes up, the amount of work
! <emphasis>per node</emphasis> increases in a merely linear
! fashion. </para>
! 
! <para> This needs to be tempered further, as people have had the
! habit of pointing at this portion of the documentation and crying
! <quote>quadratic increases in replication costs!!!</quote> (When it
! wouldn't be surprising if, quite frequently, those that are crying out
! this way mightn't necessarily know what O(n^2) truly implies...)
! </para>
! 
! <para> This is a set of overhead which is added to the work actually
! done on <emphasis>replication.</emphasis> If there is very little in
! the way of INSERT/UPDATE/DELETE work to replicate, then this overhead
! will quickly become dominant, but, by the same token, there's very
! little <emphasis>real replication work</emphasis> to be done, in which
! case this presents little problem.  On the other hand, if there is a
! <emphasis>lot</emphasis> of replication work to be done, the SYNC
! events will tend to grow, whereas the <quote>confirmation
! bookkeeping</quote> <emphasis>doesn't</emphasis> increase in quantity,
! and should be able to be buried in the noise of the <quote>real
! work.</quote> </para>
! </listitem>
  
  </itemizedlist></para>
***************
*** 310,316 ****
  <para>This points to it being a bad idea to have the large
  communications network resulting from the number of nodes being large.
! Up to a half dozen nodes seems pretty reasonable; every time the
  number of nodes doubles, this can be expected to quadruple
! communications overheads.</para>
  </sect1>
  
--- 335,359 ----
  <para>This points to it being a bad idea to have the large
  communications network resulting from the number of nodes being large.
! Up to a half dozen nodes is known to behave reasonably; every time the
  number of nodes doubles, this can be expected to quadruple
! communications overheads.  Of course, the expected benefit from having
! more nodes is likely to fall each time you add an additional subscriber,
! so the value of adding huge numbers of nodes is likely to be pretty
! low.</para>
! 
! <itemizedlist>
! 
! <listitem><para> Adding the first subscriber provides a failover
! target, which is likely to be mighty valuable. </para></listitem>
! 
! <listitem><para> Once you have 5 potential failover targets, the risk
! of losing all of them should be low.  And the added complexity of
! having an extra node which needs to be configured, installed, and
! monitored is eventually likely to outweigh the value of having that
! failover target, when multiplied by the <emphasis>very
! small</emphasis> likelihood of this being <emphasis> The
! Target</emphasis> in case of failover. </para></listitem>
! 
! </itemizedlist>
  </sect1>