On 9/25/2007 4:21 AM, Marko Kreen wrote:
> On 9/22/07, Decibel! <decibel at decibel.org> wrote:
>> Actually, what I'm really wondering is if a "commit ID" analogous to a
>> transaction ID but set at commit time (and in order of commits) would
>> vastly simplify things...
> 
> Could you clarify?  I don't get it.  Assuming we keep the trigger
> based event logging, the event storage happens at the time of
> insert/update/delete statement, how can anything determined at
> commit time be useful?

I think his theory is about a replication protocol that applies changes 
on slaves in the commit order of the master. Using such protocol would 
certainly simplify things, since all the slave has to do is to remember 
the last commit ID applied, then select all changes with a higher commit 
ID next time.

The flaw in that theory is that such protocol would assume an index over 
the commit ID. Without that index, the entire log would have to be 
sequentially scanned and sorted each round, so there would not be any 
benefit to that. But such index cannot be maintained easily because the 
commit ID isn't known at insert time, so the tuples would have to be 
revisited after the transaction committed.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #