"Henry" <henry at zen.co.za> writes:
> btw, I've occasionally noticed the following slony activity on the slaves:
>
> "update table set id=100 where id=100"
>
> (where id is the primary key)
>
> wtf?  Presumably this is some kind of replication artifact or -something-.
> Problem is, this kind of weird update on *HUGE* tables on the slaves could
> be what sometimes contributes to lag...
>
> Any idea what this is about?

This would be the case where something is updating tuples on the
origin, and not even actually changing any data.

Thus, perhaps, 
   update table set status = 'done' where created_on > '2007-08-31';

where there are a bunch of tuples with "created_on > '2007-08-31'"
which have status = 'done' already.

That would be a case where I'd sorta like to change the query to:
   update table set status = 'done' where created_on > '2007-08-31' and status <> 'done';

The latter query would not cause Slony-I "logtrigger()" triggers to
fire in cases where the status was already 'done'.

This is by design; note that...

- On the origin, all the tuples did get touched, which would mean that
  "ON UPDATE" triggers on the table would fire;

- We preserve that semantic on the subscriber.
-- 
(format nil "~S@~S" "cbbrowne" "linuxfinances.info")
http://linuxdatabases.info/info/linux.html
Developmental Psychology
"Schoolyard behavior resembles adult primate behavior because "Ontogeny
Recapitulates Phylogeny" doesn't stop at birth."
-- Mark Miller