One of the 1.1 changes is the notion of "dynamic SYNC grouping," where
the idea is to dynamically increase the number of SYNC events grouped
together.

The point:

1. If a replica is way behind, grouping a bunch of them together saves
   on transaction overhead, cuts down on the need for logging, and
   probably makes some of the queries more efficient.

This is what the "-g" option in slon is all about.

There are also two other considerations:

2. If one SYNC winds up being really big (e.g. - due to a transaction
   like "update SOME_TABLE set last_updated = now();"), then there's no
   real value in grouping that with anything else.  A transaction could
   be so big it causes grief so that you'd only want to apply SYNCs one
   at a time.

3. Supposing some SYNC causes grief when combined with another, it
   would be a Bad Thing if a "-g 42" meant that the slon falls into a
   'trap' where it will _never_ get past two SYNCs that the policy
   keeps grouping together.  (Haven't seen it, but I can imagine
   it...)

Thus, the notion of a dynamic policy for grouping them.

Rule #1.  When slon starts, start by doing 1 sync.

          That way you don't fall into the trap of #3.

Rule #2.  Add to that incrementally; do 1, then 2, then 3, and so
          forth.  Thus, you gradually move towards "lots."

Rule #3.  Look at some time-based evaluation to say "enough."

          Doing 2 minutes worth of work in one SYNC group is probably
          plenty to get all the savings you wanted in Principle #1.

Rule #4.  One you catch up, fall back to the "conservative" policy.

          Once we're caught up, the next sync group will only have
          1 SYNC to work with, so we drop back to a group size of 1,
          and work up from there only if we fall behind for some
          reason.

Here's an instance of being behind by about 100 SYNCs, and catching up
quickly.  In this case, you can see the grouping based on the Log
Shipping file numbers...

% ls -l | tail -something | cut -d ":" -f 2 | cut -b -f 3-
slony1_log_11_00000000000000004189.sql
slony1_log_11_00000000000000004190.sql
slony1_log_11_00000000000000004192.sql
slony1_log_11_00000000000000004195.sql
slony1_log_11_00000000000000004199.sql
slony1_log_11_00000000000000004204.sql
slony1_log_11_00000000000000004210.sql
slony1_log_11_00000000000000004217.sql
slony1_log_11_00000000000000004225.sql
slony1_log_11_00000000000000004234.sql
slony1_log_11_00000000000000004244.sql
slony1_log_11_00000000000000004256.sql
slony1_log_11_00000000000000004270.sql
slony1_log_11_00000000000000004286.sql
slony1_log_11_00000000000000004297.sql
slony1_log_11_00000000000000004298.sql
slony1_log_11_00000000000000004299.sql
slony1_log_11_00000000000000004300.sql
slony1_log_11_00000000000000004301.sql

It's not a big thing, but it should make Slony-I better behaved in
environments where there's a tendancy for replicas to fall behind...
-- 
"cbbrowne","@","ca.afilias.info"
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)