> 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
>
