On E, 2005-04-11 at 09:19 -0400, cbbrowne at ca.afilias.info wrote:
> > Does anyone have any #s on how fast Slony works?
> >
> > On all my current uses, there aren't a heavy number of
> > 'insert/update/delete's happening, so of course, it never falls behind ...
> >
> > If one were to have a 'write master' with a bunch of 'read subscribers', I
> > imagine there is a point where the writes to the subscribers would start
> > to get delayed, right?  Has anyone hit such a limit?
> 
> I haven't seen that limit; I would expect it to be surprisingly high, and
> I know of a useful workaround.
...
> Furthermore, all the rest being said, it's pretty easy to get Slony-I to
> "bog down;" you just need to do heavy updates that get applied "en masse".
>  As with:
> 
>   update some_replicated_table set updated_on = now() where id in
>      (select id from some_replicated_table limit 5000);
> 
> That one query creates 5000 updates, which, from Slony-I's perspective,
> are 5000 _individual_ updates.  5000 entries in sl_log_1, and such.

another way to easily bog down Slony is to have some really long
transactions, which prevent some significant tables from being cleaned
up by vacuum. The most relevant of these is pg_listener, which has no
index on it, so having a 24-hour query (either VACUUM, COPY (from
slony's subscribe or other), all commands from single run of pg_dump, or
just an open psql connection after begin; + some queries) can grow
pg_listener big enough to make any event propagation take tens of
seconds and causing replication to fall behind significantly.

-- 
Hannu Krosing <hannu at skype.net>