| Hannu Krosing 2005-09-24, 8:24 pm |
| 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-7C/ iILuz2RdeoWH0uzbU5w@
public.gmane.org>
|