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

Tatsuo Ishii ishii at postgresql.org
Thu Jun 6 10:24:41 JST 2013


> 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?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp


More information about the pgpool-general mailing list