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
