On Mon, Jan 07, 2008 at 12:43:53PM -0500, Christopher Browne wrote:
> I have been looking at this idea for a while, and I *think* it has
> enough merit to consider implementing it.

[&c.] 

This proposal seems like a good idea to me, but I think particular community
input is needed on a couple areas.

>   1.  Some processing load gets taken off the provider

[. . .]

>   2.  Processing load is moved from slon to subscriber DBMS

What this means, of course, is that load goes down on the origin and up on
every subscriber.  This seems to me to be obviously desirable, but I wonder
if there's anyone who has designed specifically around the load profile of
Slony today, and who will have problems with this new load profile.  Anyone?

>       An important question: Will that loop lead to grossly excessive
>       backend memory usage in cases where Large Tuples are processed?
>       (e.g. - where the INSERT statement is inserting a tuple
>       consisting of 40MB of data)

This is obviously an empirical matter, but I suggest people need to start
thinking very carefully about possible test cases -- particularly unusual
and expensive ones -- now.  The worst effect of this change would be if we
traded load on the origin for lighter load that only works 95% of the time. 
Reliability is, I think, the cardinal value in this system, and everything
else needs to be sacrificed to that.

>       There is a downside: with this approach, we now have no option
>       for a subscriber node to NOT be configured to be a provider; all
>       nodes now load data into the sl_log_? tables.

Does anyone care about this?  It strikes me that the subscribe-only option
is a frill that could be traded away, but if people are dedicated to it, now
would be a good time to speak up.

I like the proposal, but it'd be nice to here widespread agreement on a
change that is a fairly deep architectural one before we go ahead with this
strategy.

A