From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Markus Wanner <markus(at)bluegap(dot)ch> |
Cc: | Gregory Stark <stark(at)enterprisedb(dot)com>, David Fetter <david(at)fetter(dot)org>, chris <cbbrowne(at)ca(dot)afilias(dot)info>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Postgres-R: primary key patches |
Date: | 2008-07-18 16:30:08 |
Message-ID: | 20080718163008.GD4042@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | David E. Wheeler | 2008-07-18 16:53:31 | Re: PATCH: CITEXT 2.0 v4 |
Previous Message | Tom Lane | 2008-07-18 16:23:25 | Re: [PATCH]-hash index improving |