Andrew Sullivan <ajs at crankycanuck.ca> writes:
> On Wed, Jul 04, 2007 at 10:10:08AM -0400, Jan Wieck wrote:
>> seems pretty deterministic, doesn't it? But the result of it depends on 
>> the exact commit order and the transaction isolation level. We don't 
>> capture the commit order of single transactions, nor do we care for it 
>> anywhere in the Slony-I logic.
>
> I think this is key.  The current arrangement solves the problem
> where the visibility rules as they were in force on the origin are
> followed while applying on the replica.  You're going to need to do
> quite a bit of theoretical work here to show that the agreeable order
> rules are followed in any grouping approach you take.  Please see the
> original concept paper on this exact point.  MVCC is hard.

The only change I'd propose in handling grouping is to
opportunistically see if there are consecutive operations that may be
trivially joined together.

In effect, if the *old* logic generated the sequence of queries:

  delete from my_table where id = 25;
  delete from my_table where id = 82;
  delete from another_table where id = 19;
  delete from my_table where id = 45;

then there is only one "joining" possible, which is to combine the
first two delete queries into one, so that the overall sequence of
queries becomes thus:

  delete from my_table where id = 25 or id = 82;
  delete from another_table where id = 19;
  delete from my_table where id = 45;

That doesn't change anything about "agreeable ordering" as far as I
can see.

Of course, that example isn't much of a "win."  What would be way more
interesting (from a performance perspective) is the case where there
are 25 deletes in a row from my_table that could be folded together.
-- 
(reverse (concatenate 'string "ofni.sesabatadxunil" "@" "enworbbc"))
http://linuxdatabases.info/info/sgml.html
Health is merely the slowest possible rate at which one can die.