Richard Yen <dba at richyen.com> writes:
> Wondering if anyone has ever attempted this...
>
> Is it possible for node B to subscribe table X from node A on set 2
> (new set), then turn around and have node B provide table X to nodes C
> and D on set 1 (existing set)?
>
> I suppose it's easier for nodes C and D to subscribe to node A on set
> 1, but if we could do it the above method, I'd believe there would be
> less network traffic
>
> Thanks for any comments/suggestions!

In principle, something like this would be at least conceivable, as
what is stored in the log tables is not the set ID, but rather the
origin node, so if we somehow tied this table + origin to a different
set on the different nodes, what you describe would be at least sort
of possible.

However, the association of tables to sets is done on a cluster-wide
basis, and it would be a rather big design change to decouple that.

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.

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.
-- 
let name="cbbrowne" and tld="cbbrowne.com" in name ^ "@" ^ tld;;
http://cbbrowne.com/info/nonrdbms.html
Rules of  the Evil Overlord  #210. "All guest-quarters will  be bugged
and monitored so that I can keep track of what the visitors I have for
some reason allowed to roam  about my fortress are actually plotting."
<http://www.eviloverlord.com/>