Hi Hannu,

I just run VACUUM before doing the copy dump, because I knew that this
could behave strange without a VACUUM before.

I will make the same dump today again and see what happens - maybe the
cause was somewhere else and not slony related - as you said.

Hannu Krosing wrote:
> On L, 2005-09-24 at 18:32 +0100, Aldor wrote:
> 
>>Hi,
>>
>>I don't really know how Slony works internally but I know that it uses
>>some triggers for getting out new transactions.
>>
>>The config of my Slony cluster:
>>
>>--- CONFIG START ---
> 
> ...
> 
>>--- CONFIG END ---
>>
>>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.
> 
> 
> Are you running this on live db, i.e. are these other tables actively
> updated and replicated ?
> 
> How long is the time for loading the dumps ?
> 
> 
>>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?!
> 
> 
> Slony triggers should not directly affect the tables they are *not* used
> on.
> 
> For longer transactions, when tables pg_listener, sl_log_1 and others
> start to grow into megabytes in size, queries issued by slon can
> sometimes misbehave, eat tons of CPU, wait for several minutes for locs
> on pg_listener and do other bad things bogging the whole database down.
> 
> But this is through secondary effects of *any* long transactions, not
> the slony *triggers* on unrelated tables.
> 
> OTOH, you may be just some effects of not having run vacuum or analyse
> often enough resulting in sharp performance drop, completely unrelated
> to slony.
>