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. -- _______________________________________________ Slony1-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/slony1-general
