Re: Postgres-R: primary key patches - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Postgres-R: primary key patches
Date
Msg-id 20080718163008.GD4042@alvh.no-ip.org
Whole thread Raw
In response to Re: Postgres-R: primary key patches  (Markus Wanner <markus@bluegap.ch>)
Responses Re: Postgres-R: primary key patches  (Markus Wanner <markus@bluegap.ch>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH]-hash index improving
Next
From: "David E. Wheeler"
Date:
Subject: Re: PATCH: CITEXT 2.0 v4