On E, 2005-09-05 at 18:36 -0400, Christopher Browne wrote:
> 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.

My plan was to modify the query to have a group by and some kind on
list-making aggregate for set ids.

But It looks like pg 8.0 does the optimisation by itself (collapses <xid
filter>s and makes a big list of ORs of all the log_tableid in(...)
clauses - essentially doing what I described - so the problem may go
away by just sitting on it :) ) 

> 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.

If using a join to sl_table could change a long list of OR's to im-
memory hash lookup, that could be a further win on CPU usage. But only
testing will tell it.

-- 
Hannu Krosing <hannu at skype.net>