[Pgpool-general] pgpool vs application managed db connection pooling

Bryan Varner bvarner at polarislabs.com
Fri Oct 28 14:52:34 UTC 2011


I currently have pgpool in testing under a large(ish) java application.

I have tested all the scenarios you mention, here are my results -- 
yours will likely vary.

We're using C3P0 for both application level connection pooling, and 
statement pooling. Statement pooling has proven to be a huge performance 
boost for our application.

> Please share any pros/cons for using:
> 1) just pgpool managed db connection pool vs

Having pgpool underneath will allow us to load-balance selects across 
the cluster. Our application workload is insert / update heavy on 
regular cycles, but read-heavy for data that's older than 1 hour.

In addition, using pgpool to trigger a failover may be easier than some 
other alternatives.

> 2) just application managed db connection pool vs

This is our current production situation. We have a rather strange 
application-level pool of pools to balance report queries across the 
nodes in our replicated cluster.

I have never had an issue with application level connection pools, they 
preform reliably, and work effectively. The overhead involved with JDBC 
connections is very high.

I tested removing the application-level connection pool and relying 
solely on pgpool, opening connections with the JDBC driver as needed. 
The performance was still better than without pgpool, but it was 
atrocious compared to with the application level pool in place.

> 3) both pgpool and application managing their own separate db
> connection pools at the same time?

There's some trickery here in configuring pgpool and your application 
connection pool so that you don't exhaust the pgpool pool and deadlock 
your application pool.

I've seen marked improvement doing select-heavy loads with load-balance 
mode enabled. It's really nice.

I have not seen any degradation in performance, I've seen marginal 
improvement.

I hope this helps -- I don't have official load-test numbers at this 
time, or else I'd be including those here. The pgpool testing we've been 
undertaking hasn't made it up to our load-test environment yet -- once 
it's there, I plan on reporting my results.

Regards,
-Bryan Varner

> Kind regards,
> Stevo.
> _______________________________________________
> Pgpool-general mailing list
> Pgpool-general at pgfoundry.org
> http://pgfoundry.org/mailman/listinfo/pgpool-general



More information about the Pgpool-general mailing list