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.
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 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
