-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jean-Paul Argudo a écrit :
> 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?...

There will either ways be 300 000 update queries to propagate, I guess.

> 
>> 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.
> 

Well, let me try to explain what I thought...

If MBT was in a particular set, with the same subscribers than the other set
that contains all other objects, would slony keep objects in sync in the second
set while the first set begins to lag, due to many events originating from MBT
on that set ?

In other words, are there two distinct treatments for two sets that originate
from the same node and subscribed by the same subscribers ?

I tried, and the answer is ... no. the two sets will lag.

It seems useless, then, to declare a specific set for that table.

Regards,
SAS
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKMSlNA+REPKWGI0ERAtPkAJ9NNiFwHwXXeR47b5kGH1ImTcq8XACgnjwb
9c2XmZQdkBrgRJt0J7XpNG4=
=llrZ
-----END PGP SIGNATURE-----