From: | Peter Geoghegan <peter(at)2ndquadrant(dot)com> |
---|---|
To: | A B <gentosaker(at)gmail(dot)com> |
Cc: | postgresql Forums <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Feature request: Replicate only parts of a database |
Date: | 2011-05-27 09:58:16 |
Message-ID: | BANLkTinUySgKbMhO9D6tu1H+Aka5fgBJEQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 27 May 2011 05:53, A B <gentosaker(at)gmail(dot)com> wrote:
> I have a small problem, in a database I need to export parts of a
> database table to another server, and I could easily accomplish ( I
> hope) that by creating a view and select * from the view and send it
> over to the other server or use triggers to record what rows are
> inserted and deleted. (I have not written that part yet)
>
> With the new very nice streaming replication, I think it would be much
> better if the database could send the data directly to the other
> server instead of having to write my own sync-script.
> But I don't want to sync the entire database since only a very small
> fraction of the data should be replicated.
That isn't going to happen, because of the way streaming replication
is implemented. Besides, you haven't even described what interface
such a feature would actually have. How would it know which tuples to
replicate? Is that really a more sensible interface than just being
able to selectively replicate a subset of tables?
Consider a trigger-based replication system like Slony or Londiste,
which allow asynchronous replication at table granularity.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Sullivan | 2011-05-27 10:54:47 | Re: Feature request: Replicate only parts of a database |
Previous Message | Stuart Bishop | 2011-05-27 09:08:49 | Re: max_connections proposal |