Michael Crozier <crozierm at conducivetech.com> writes:
>> ((A and X) or (B ?and X)) ==> ((A or B) and X)
>>
>> (A = log_tableid in ([set1])) and (B = log_tableid in ([set2]))
>> ? ?==> (A or B) = log_tableid in ([set1] + [set2])
>>
>> what more proof do you need ?
>
> After looking at the code (though I am not very familar with slony internals 
> yet), it seems that the <xid filter> parts are calculated per-set, so it 
> would have collapsed IF the xid parts were the same or it would require proof 
> that the xid filter parts will always be the same.

Right.  That's why I'm not leaping at the change.

In any case, it appears that adding the index on log_xid is an
enormous improvement *without* making any code changes.  If that gives
the "big win," then I'm _really_ disinclined to change the query.

>> I guess that in my case the improvement was more like 95%.
>
> I also saw a significant increase.  The difference between my "fast" machine 
> and "slow" machine seemed to indicate that the difference was primarily CPU 
> related.

That's consistent with it using a seq scan and having to sort the table.

> I will also note that during the "catch up" period after a long
> copy, the event group size heuristic was not working very well, even
> when adjusting the desired sync time to various values.  The size of
> the group was affecting the event processing time very little, so
> the group size would gradually reach 100, then drop back down to 1.
> I eventually modified remote_worker.c to keep the group size at 100,
> which decreased the catch up time by approximately 90% and kept the
> sync length below the 100000 (artificial?) limitation.
>
> I'm not familiar enough with the algorithm to suggest an
> improvement, but I can say that the immediate "back off down to 1"
> was the performance killer.

Oh, dear.

Fortunately, you can deactivate that at runtime by setting the time
it's trying to aim at to 0.
-- 
"cbbrowne","@","ca.afilias.info"
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)