>
> I'm curious as to why you expect there to be less network traffic.  It
> seems to me that the main traffic would come from query application,
> and I don't see any reason for the change you are suggesting to cut
> down on that.
>
Well, the way we've got this set up is table X has copies of itself on  
three clusters.  So among the three clusters, there's already network  
connections open to each of their respective nodes.  The new thing we  
want to do is to create a "master copy" of table X, so that we can  
just update once, and the changes would propagate to the three other  
clusters.  If each node in each cluster were to create a new network  
connection to this "master copy" node, that would increase network  
traffic; if we just left it to the providers on each cluster to  
propagate to its subscribers, we'd use existing network connections,  
and it would possibly be cleaner.  Hence, the desire for the table to  
subscribe via one setID, and provide via another setID.

> The *possible* change would be for there to be less network traffic as
> a result of fewer events propagating, but I don't see that changing
> network traffic particularly materially.
True.  In terms of net bytes transferred, there's no difference.  I  
suppose it's just the thought of more network connections that  
initially raises flags.

--Richard