> Tatsuo,
> > Yes. However it would be pretty easy to modify pgpool so that it could
> > cope with Slony-I. I.e.
> >
> > 1) pgpool does the load balance and sends query to Slony-I's slave and
> >    master if the query is SELECT.
> >
> > 2) pgpool sends query only to the master if the query is other than
> >    SELECT.
> >
> > Remaining problem is that Slony-I is not a sync replication
> > solution. Thus you need to prepare that the load balanced query
> > results might differ among servers.
> Yes, please, some of us are already doing the above ad-hoc.
> The simple workaround to replication lag is to calculate the longest likely 
> lag (<3 seconds if Slony is tuned right) and have the dispatcher (pgpool) 
> send all requests from that connection to the master for that period.   Then 
> it switches back to "pool" mode where the slaves may be used.

Can I ask a question?

Suppose table A gets updated on the master at time 00:00. Until 00:03
pgpool needs to send all queries regarding A to the master only. My
question is, how can pgpool know a query is related to A?
Tatsuo Ishii

> Of course, all of the above is only useful if you're doing a web app where 
> 96% 
> of query activity is selects.   For additional scalability, put all of your 
> session maintenance in memcached, so that you're not doing database writes 
> every time a page loads.
> -- 
> Josh Berkus
> Aglio Database Solutions
> San Francisco

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to [EMAIL PROTECTED] so that your
      message can get through to the mailing list cleanly

Reply via email to