Christian Storm wrote:
> Mark,
> 
> I would recommend reading the pgsql performance link I've included  
> below.  You can see that I too was flirting with pgmemcache.  The two
> issues that prevented me from using it were
> 
> 1) The race condition that exists when the memcache and postgres data  
> are out of sync and
> 2) The integrity of the data in the cache
> 
> The thought is that a new PG feature, an ON COMMIT trigger (there is  
> some debate, at least in my mind, whether BEFORE and/or AFTER COMMIT  
> would be useful), or ON PREPARED TRANSACTION, would solve both these  
> problems given PG's MVCC model.  The race condition would be greatly  
> diminished since PG and memcache would be updated nearly at the same  
> time.  Also, if the transaction failed the cache wouldn't be updated.
> 
> Unfortunately, this doesn't exist, so to me pgmemcache has limited  
> use unless you believe all your transactions will always succeed and  
> you don't care about race conditions.
> 
> Hopefully that helps you in your decision.
> 
> http://groups-beta.google.com/group/pgsql.performance/browse_frm/ 
> thread/f345107f382a7aee?tvc=1&q=pgmemcache&hl=en

Thanks for the response Christian. The site in question is busy enough
that we have seen failures in the past related to race conditions, and
we do have rare transaction failures.

I think this enough to scare me away from pgmemcache for now.

In other news, I'm having initial luck testing Perl's DBD::Multi (for
load balancing) along with Slony.

I've created a second "read only" handle for load balancing, and I'm
starting to go through the application to change some SELECTs to use the
read-only handle, which may then hit just the slave, or the slave and
master, depending on the setup.

I still need to more benchmarks and real-world testing to verify the
approach works suitably.

    Mark