Hi Stéphane,

>  2. drop MBT out of replication, update it, and then add it back to the
> replication;

The best option so far IMHO. But what's better? Let transit 320K
modified rows or 6M new rows ? I really don't know there.

> [...]
> That's why I thought of solution 2. BTW, updating 320 000 rows on master could
> take some 20 minutes or so.

I just wonder why didn't you partitionned MBT? In that particular case
it could improove things, right ?

Not only for replication purpose, but in general ?

I wonder whats the impact for slony in replicating from 1 table of 6
millions row, or, lets say, 6 tables of 1 million rows? What if 12
tables of half-million, etc?...

> What's more I wonder if slony could work two sets in parallel so that I don't
> have to wait for MBT to be updated and other tables can stay in touch with
> master while processing MBT updates.

Im' sorry, I don't get the parallel thing here.

-- 
Jean-Paul Argudo
www.PostgreSQLFr.org
www.Dalibo.com