On Mon, Oct 18, 2010 at 1:27 PM, Robert Haas <robertmh...@gmail.com> wrote: >> It'd be kinda cool if we had it, but the work required to get there >> seems far out of proportion to the benefits ... > > I agree. I think that's backing into the problem from the wrong end. > The limiting factor here is that we require the entire cluster to be > replicated. If you could replicate individual tables/schemas, then > this problem disappears. Of course, that's not easy either, but if > you're going to solve a really hard problem, you might as well pick > that one.
That seems like an orthogonal issue. You can have a replica with fewer objects -- which requires ignoring parts of the logs -- or more objects -- which requires being able to do local modifications and have local transaction states independent of the master. They're both potentially useful features and neither replaces the need for the other. Simon talked about filtering the transaction logs a while back and got a lot of pushback. But the more uses we put the slaves to the more it will come up. I figure we'll eventually do something for this though we might want more experience with the current setup before we dive into it. Adding extra objects in the slaves sounds massively harder. The idea of using temp tables might be a useful simplification because in the general case what you want is a separate set of xids with a separate clog and wal. That sounds like it would be a lot more complex. Another possibility though is to use the MED stuff. If we could support creating tables locally that were actually hosted by a separate database then you could do updates, inserts, etc against those tables since they're actually happening in the remote database. Alternately you set up your slave to be the target of remote tables in a read-write data warehouse database. But this approach has limitations of its own until our MED implementation is a lot more powerful than it is today. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
