On Mon, 11 Apr 2005, Darcy Buskermolen wrote:

> On Monday 11 April 2005 09:06, Hannu Krosing wrote:
>> 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.
>
> I quite often test slony with the following logical layout
> http://www.dbitech.ca/slony/slony-testing.png  All DB's are running on 1
> PostgreSQL cluster, using the basic pgbench to generate load.

'k, if I'm reading the diagram properly, you are doing cascading 
subscribers?  dbitech -> arch/sparc ... sparc -> freebsd/aix ... freebsd 
-> delenn/bestestpuppy/darcy-2000?

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy at hub.org           Yahoo!: yscrappy              ICQ: 7615664