On Sun, 3 Dec 2006, Jim Nasby wrote:

> Nor would I, but one possibility that comes to mind is adding the
> ability to determine the sequence of transaction commits. Currently,
> Slony has no choice but to skip from one consistent state to the
> next, and for at least some of that it also has to know what XIDs
> were uncommitted in a batch. I have to wonder if there's a better way.

Is that going to buy us much?  How much time is spent trying to figure out 
what needs to go into a consistent snapshot? (Versus extracting the data).
DBMirror guessed at the commit order and replayed all of the transactions in 
that guessed order.  Even excluding the 'guessing' part I'm not convinced 
that worked better than going from one consistent set to the next.




>
> Though, the counter-argument is that batching greatly reduces the
> load on the slaves...
>
> Something else I've noticed is that slaves pulling data from a master
> present a non-trivial load (seeming much larger than the triggers
> that log the data), so perhaps there is something to be had there as
> well.
> --
> Jim Nasby                                            jim at nasby.net
> EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)
>
>
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/slony1-general
>