I think there are 2 questions in Dmitry's email.
1) How to minimize the workload on the master while still having a low time 
lag between master and slave
and
2) How to coordinate or synchronize the master/slave so the application can 
reliably update the master and query the slave for the just-updated data 
without getting old/stale data.

On 1, it sounds like the workload is directly proportional to the number of 
direct slaves the master has and somewhat proportional to the 
sync_interval/time lag setting.  Correct me if I'm wrong here.

This second question is one that I have also been struggling with.  We would 
like to direct all inserts/updates/deletes to the master but send all 
selects to the slave(s).  However, our app routinely makes updates and 
immediately queries back the (just-updated) data.  Any suggestions on how to 
do this without a bogus and unreliable wait/sleep call?  Does Dmitry's idea 
make sense??

Thanks,
Bill

----- Original Message ----- 
From: "Christopher Browne" <cbbrowne at ca.afilias.info>
To: <dmitry at koterov.ru>
Cc: <slony1-general at lists.slony.info>
Sent: Sunday, May 13, 2007 6:57 PM
Subject: Re: [Slony1-general] How to reduce the time data appears in the 
slave?


> "Dmitry Koterov" <dmitry at koterov.ru> writes:
>> So, if anybody reads from sl_log_status, it blocks until anything is
>> written to sl_log_status. Seems it will be fully transparent for
>> Slony, but decreases the amount of polling queries. (It is an idea
>> only, practical implementation may need to be more detailed.) What
>> do you think about it?
>
> It smells to me as though you're trying to optimize the wrong problem.
>
> The "pg_listener problem" is one that changes in 1.2 *mostly*
> rectifies; the costs associated with NOTIFY/LISTEN should be dropped
> to a dull roar in 1.2.  (There are further optimizations in CVS HEAD,
> but it shouldn't be *highly* relevant.)
>
> What hasn't been touched, and in a sense, can't be, is to reduce the
> load of processing the queries against the "master" node that pull
> replication data to feed to the subscribers.
>
> I suspect that it is THOSE queries that are causing you trouble, as
> opposed to anything about NOTIFY/LISTEN.
>
> If you have nine nodes all feeding off the master, that's going to put
> considerable load on the master node.  And THAT would easily cause
> things to slow down on the master, and cause replicas to lag.
>
> The fewer nodes that feed directly from the origin, the less load that
> you put on the origin, and the easier it should be able to feed them.
> -- 
> select 'cbbrowne' || '@' || 'ca.afilias.info';
> <http://dba2.int.libertyrms.com/>
> Christopher Browne
> (416) 673-4124 (land)
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-general