Re: Postgres-R: primary key patches

Hi,

I realize that you are talk about Slony, let me answer for the
Postgres-R case, anyway.

Gregory Stark wrote:
> Hm, it occurs to me that really Slony should be saying
> WHERE (col1,col2,...) = ('x','y','z',...)

Hm.. that would mean increasing the amount of work for the remote
backend, which applies remote transaction. For scalability reasons, I'm
trying to keep that minimal.

> and letting the server figure out what access method is best for finding the
> candidate record. That could mean using the primary key index, or it could
> mean using some other index (perhaps a partial index for example).

For Postgres-R, I think that would only be a gain in those cases, where
all tuples of a collection (or even the entire change set) only affect
tuples from a partial index. That doesn't look like it's worth the
trouble, IMO. Or do you think that's a frequent case?

Thinking about it, I'd even say that requiring only one index frequently
is favorable because of caching effects. Dunno.

> 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).

Maybe I'm thinking too much in terms of Postgres-R, instead of Slony,
what you are talking about.

Regards

Markus