Hello Chris,
chris wrote:
Slony-I does the same, with the "variation" that it permits the option
of using a "candidate primary key," namely an index that is unique+NOT
NULL.
If it is possible to support that broader notion, that might make
addition of these sorts of logic more widely useful.
Well, yeah, that's technically not much different, so it would probably
be very easy to extend Postgres-R to work on any arbitrary Index.
But what do we have primary keys for, in the first place? Isn't it
exactly the *primay* key into the table, which you want to use for
replication? Or do we need an additional per-table configuration option
for that? A REPLICATION KEY besides the PRIMARY KEY?
I know Jan Wieck has in mind the idea of adding an interface to enable
doing highly efficient IUD (Insert/Update/Delete) via generating a way
to do direct heap updates, which would be *enormously* more efficient
than the present need (in Slony-I, for instance) to parse, plan and
execute thousands of IUD statements. For UPDATE/DELETE to work
requires utilizing (candidate) primary keys, so there is some
seemingly relevant similarity there.
Definitely. The remote backend does exactly that for Postgres-R: it
takes a change set, which consists of one or more tuple collections, and
then applies these collections. See ExecProcessCollection() in execMain.c.
(Although, I'm still less than thrilled about the internal storage
format of these tuple collections. That can certainly be improved and
simplified.)
Regards
Markus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
