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.

-- 
Hannu Krosing <hannu at skype.net>