> Supposing we had a single column primary key, it ought to be 
> possible for
> the slon to recognize:
> 
>  - I'm issuing "delete from foo where id = x;"
> 
>  - Hmm.  The next statement is "delete from foo where id = y;"
> 
>  - That could be folded into the statement:
>      delete from foo where id in (x, y);
> 
>  - If we keep deferring, we might discover that the next statement is
>      delete from foo where id = z, which could turn that into...
> 
>      delete from foo where id in (x,y,z);
 
This sounds like a viable way to reduce the number of statements to propagate.  You're right, however, in that it is only really clean for tables with a single column primary key.  In our tables we tend to have a serial column as the primary key and set up unique contraints on groups of columns where we don't want duplicates of combinations, so we end up with sl_log delete entries containing sequential clauses (recid = 1, recid = 2, etc...).

> Alas, I'm not sure I know how to do this if a composite 
> primary key is in
> use, or, more particularly, if the big series of OR clauses that would
> result will "play well" the way the "in clause" should.
> 
> e.g...  Is it any use to submit:
> 
>   delete from foo where (id1 = x1 and id2 = y1) or (id1 = x2 
> and id2 = y2)
> or (id1 = x3 and id2 = y3) or ...
> ???

How are deletes for tables with composite keys written to the sl_log tables?  I've only had experience with the single column pk deletes.  Perhaps someone who uses these a lot has an idea for grouping them...?

> This would be a fairly significant restructuring of the 
> update submission
> loop, as this needs to defer all deletes.  Are you keen on prototyping
> that?
> 

The problem here is that I don't think all deletes can be deferred.  This logic would only apply until the first non-delete statement is encountered.  Take the situation where a delete removes a record, and then a record is inserted that uses the same pk.


Disclaimer: Any references to Pipeline performance contained herein are based on historic performance levels which Pipeline expects to maintain or exceed but nevertheless does not guarantee. Congested networks, price volatility, or other extraordinary events may impede future trading activities and degrade performance statistics.