Aldor <an at mediaroot.de> writes:
> I don't really know how Slony works internally but I know that it uses
> some triggers for getting out new transactions.
>
> Of course I have also other tables in the same database, which I
> don't want to cluster. When making big data dumps into that tables I
> noticed that since I'm using Slony on that database, buf for another
> table, the big dumps are getting 5-10 times slower. The only
> explanation I have is that it has maybe something to do with Slony -
> because nothing else have been changed. May be Slony do in each row
> dump of the process any things which can slow down the process -
> even if Slony should not care about this other table?!

Can you be more precise about what it is that is slowing down?

It is not surprising that it would take longer to make modifications
to replicated tables...  For each row modified (whether
insert/delete/update), you add firing a trigger, as well as writing
information about the modified row to sl_log_1.

I could imagine cases where that would slow down insertions by a
factor of 2 or more.

But when you say "big dumps," that sounds as though you are drawing
data FROM a replicated table, and Slony-I should have NO EFFECT on
performance in that regard.  Triggers don't fire on SELECT or on a
COPY out.
-- 
let name="cbbrowne" and tld="ca.afilias.info" in name ^ "@" ^ tld;;
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)