Brad Nicholson wrote:
> On Wed, 2007-03-14 at 16:20 -0400, Chris Browne wrote:
>   
>> It's not a LOT better, but I think it's at least *somewhat* better.
>> And perhaps someone can point out a way of doing better still, perhaps
>> to not bother generating some of the tuples altogether.
>>
>> Thoughts?
>>     
>
> Is there a reason that there has to be an entry in sl_seqlog if the
> sequence doesn't change?  If not, then you should be able to insert on
> change, and do nothing for case where it doesn't change.
>   
Hmm.  That's a thought.

We pull the value as part of the COPY_SET event; that is SURE to
initialize the sequence.

If we don't bother recording a value, when it doesn't change, that means
there won't be an update to be found.  Which isn't wrong.

The case I see being a *tad* troublesome is if we are processing SYNCs
4781 thru 4820 as one "sync group."  In that case, I think the slon
looks at 4820, at present.  If the last sequence update for #21 was in
SYNC 4600, then we don't really need to change that sequence.  If the
last sequence update was in SYNC 4812, then we have to search for the
last sequence update within the current "sync group" range.

Thus, for each sequence, we're looking for...

select seql_last_value from sl_seqlog
where
   seql_seqid = 21 and
   seql_origin = 2 and
   seql_ev_seqno = (select max(seql_ev_seqno) from sl_seqlog where
seql_seqid = 21 and seql_origin = 2 and seql_ev_seqno between 4781 and
4820);

Doing this in one "swell foop" as one query seems troublesome :-(

But I think you may be onto something here...