I did some very detailed tests and found out that Slony wasn't really
guilty. Running slony with many daemons for another database and two
daemons for the mentioned problem database was hurting the power of the
database server just a little bit.

The problem was something else and had nothing to do with Slony.

Slony is doing his work quite good.

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.