Hi Christopher,

I was talking about tables which are NOT in the replication set.

Christopher Browne wrote:
> 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.