On 12/12/13 11:13 AM, Robert Haas wrote:
I think it sucks (that's the technical term) to have to wait for all
currently-running transactions to terminate before being able to begin
streaming changes, because that could take a long time.  And you might
well know that the long-running transaction which is rolling up
enormous table A that you don't care about is never going to touch
table B which you actually want to replicate.  Now, ideally, the DBA
would have a way to ignore that long-running transaction and force
replication to start, perhaps with the caveat that if that
long-running transaction actually does touch B after all then we have
to resync.  Your model's fine when we want to replicate the whole
database, but a big part of why I want this feature is to allow
finer-grained replication, down to the table level, or even slices of
tables.


I know you're not going to attempt this for 9.4, but I want to mention a 
related case here. I've often wanted the ability to limit the tables a 
transaction can touch, so that it will not interfere with vacuuming other 
tables.

This would be useful when you have some tables that see very frequent 
updates/deletes in a database that also has to support long-running 
transactions that don't hit those tables. You'd explicitly limit the tables 
your long-running transaction will touch and that way vacuum can ignore the 
long-running XID when calculating minimum tuple age for the heavy-hit tables.

If we had that capability it could also be used to improve the time required to 
get a snapshot for a limited set of tables.
--
Jim C. Nasby, Data Architect                       j...@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to