Re: Postgres-R: primary key patches

Markus Wanner wrote:

> Gregory Stark wrote:

>> It would be nice if there was a way for Slony to express to the server that
>> really, it only needs any UNIQUE NOT NULL combination of columns to match.
>> Once the server has any such combination which matches it can skip checking
>> the rest. I can't think of any way to write such a query in SQL.
>
> I don't quite get your point here. For UPDATEs which change the PRIMARY
> KEY, the sender currently sends the *old* values plus the changes. In
> that case, you certainly don't want to send the entire olde tuple, but
> only the fields for *one* KEY. That's what I'm calling the replication
> key. (And currently equals the PRIMARY KEY).

I think the point here is that you need to distinguish which tuple you
need to update. For this, our Replicator uses the primary key only;
there's no way to use another candidate key (unique not null). It would
certainly be possible to use a different candidate key, but as far as I
know no customer has ever requested this.

(FWIW we don't send the old values -- only the original PK columns, the
values of columns that changed, and the "update mask" in terms of
heap_modify_tuple.)

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support