From: | Jim Nasby <jim(at)nasby(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Changeset Extraction Interfaces |
Date: | 2013-12-14 19:01:17 |
Message-ID: | 52ACAAFD.6060509@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2013-12-14 19:04:47 | Re: stats for network traffic WIP |
Previous Message | Greg Stark | 2013-12-14 18:58:26 | Re: stats for network traffic WIP |