On Fri, Aug 6, 2010 at 2:53 PM, Fharid Salomon Fernandez
<fharids at hotmail.com> wrote:
>
> Thanks For your answers, well i was thinking that to,
> but the thing is that when you put all the tables in one replication set
> when the set needs to lock itself, my whole database is going to be locked ?

Yes, and this can be a problem if you have 50,000 tables.  I've found
that with ~1000 tables I do ok, but we do all our slony / schema
modifications during maintenance windows with the application offline
anyway (and autovacuum shut down as well) because interactions between
long running slony - schema changes, autovacuum, and our application
result in priority inversion issues that make the whole system grind
to a halt waiting for autovacuum's much slower work to finish, which
of course takes hours on some tables.

We can reduce schema change times to minutes by taking the app offline
and turning off autovac while we work.

We've tried just turnning off autovac and running schema updates
through slony while still live and it's been a disaster.  We're better
off dropping replication, making schema changes, and restarting
replication in that instance.  But a new subscription takes hours and
during that time we have no slony slaves to take over should the
master fail.