On Wed, 2006-03-01 at 18:22 -0500, Christopher Browne wrote:
> Rod Taylor wrote:
> 
> >>The one "grand challenge" you'll face is that getting the subscription
> >>going, with 224GB of data, will take quite a while, which will leave
> >>transactions open for quite a while.
> >>    
> >>
> >
> >It helps if you subscribe one table at a time and merge them into an
> >existing set.
> >
> >So, Create set, add table to set, wait..., merge set.  Repeat for each
> >table.  
> >
> I'd be inclined to wait 'til the end and merge them all, but that's just
> me...

I've ran into pretty big performance problems with more than a few sets.
The query for querying for data ends up with a large number of OR's in
the where clause.

> >In fact, is there a reason that Slony doesn't do this by default?  Just
> >change ADD TABLE to spit out the 3 step process in all circumstances
> >using a set of temporary set IDs (sequence that wraps between 2^31 and
> >2^32 or something).

> Alas, if you're subscribing  the *third* node, this means you're
> repeatedly taking tables out of a set and putting them back in.  I think
> the semantics of it break down, at that point.

Doh.

I guess we go back to PostgreSQL needing a general purpose improvement
for VACUUM with long running transactions.

--