On Monday 30 November 2009 17:46:45 Hans-Jürgen Schönig wrote: > On Nov 30, 2009, at 10:32 AM, Stefan Kaltenbrunner wrote: > > the question is if filtering on the sending side is actually the > > "right thing" to do. > > It increases the overhead and the complexity on the master, > > especially if you think about different (partial) replication > > agreements for different slaves and it might also be hard to > > integrate with the planned sync/async modes. > > On the other hand if you filter on the master you might be able to > > avoid a lot of network traffic du to filtered wal records. > > I think for a first step it might make more sense to look into doing > > the filtering on the receiving side and look into actual integration > > with SR at a later stage. > one problem with not-filtering on the master is that you will end up > with a lot of complexity if you start adding new tables to a replica > because you just cannot add tables as easy as when you are doing stuff > on the slave. the procedure seems ways more complex. > in addition to that you are sending WAL which has to be discarded > anyway. > we thought about filtering "outside the master" a lot but to me it did > not sound like good plan. One possibility for the far future would be to allow filtering on a slave as well:
master ---- full replication ---> primary slave --- split ---> slaves Possibly doing only catalog recovery on the primary slave. In my opinion thats heaps more complex and not better in all situation. So I would probably write it down as a nice idea but not more. Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
