[pgpool-general: 1830] Re: PgPool vs any modern programming language.

[David Kerr]

On Jun 5, 2013, at 6:24 PM, Tatsuo Ishii <ishii at postgresql.org> wrote:

>> All Rails, Django and many Java (c3po) implementations have client side connection pools.
>> 
>> I don't believe that they can be disabled. You can set them to 1 / (thread|process)
>> but that's still many per server.
>> 
>> This means that for every Rails process there is one of these sitting on PgPool at 
>> application startup:
>> 
>> pgpool   16099 15924  0 00:36 ?        00:00:00 pgpool: app app 192.168.10.19(40509) idle
>> pgpool   16100 15924  0 00:36 ?        00:00:00 pgpool: app app 192.168.14.27(57314) idle
>> pgpool   16101 15924  0 00:36 ?        00:00:00 pgpool: app app 192.168.10.218(37869) idle
>> pgpool   16102 15924  0 00:36 ?        00:00:00 pgpool: app app 192.168.10.48(37278) idle
>> pgpool   16103 15924  0 00:36 ?        00:00:00 pgpool: app app 192.168.10.106(53541) idle
>> 
>> If a single app sever has a pool size of 10.  And i have 10 servers.
>> 
>> That's 100 _persistent_ connections to PgPool. (and hence the DB)
>> 
>> To accomidate that I need 100 initial children and 100 max_connections on the postgres side.
>> 
>> That sort of defeats the purpose of pooling. 
>> 
>> Ideally, I want PgPool to protect my database from overzealous application deployments
>> while still giving them all a chance to serve requests.
>> 
>> Is this possible?
>> 
>> How are other people handling this?
> 
> Does pgbouncer's "transaction pooling" help? Or those middlewares
> require session based pooling like pgpool?

Hmm. I had various levels of success with pgbouncer / transaction pooling with Java.
I haven't tried it yet with Rails. Disabling prepared transactions was difficult in the
java world. it may be easier in the ruby world.

of course then I don't get the load balancing of PgPool which is pretty impactful.