> > Interesting, but how would it reduce the number of connections pgpool needs > > to deal with? Unless you can't get the pooling behaviour you want from > > pgpool? Is it not pooling the connections in the way you want? > > > > In your previous message you stated you needed up to 600 concurrent > > connections, so if you also want up to 600 concurrent connections coming > > from pgbouncer you'd still need 600 pgpool backends no matter which way > > around you chain them wouldn't you? > > Per my post, most of those connections are idle most of the time. So if > I use pgbouncer in "transaction" mode, I end up with only around 35 > connections. > > We need pgpool because of the load balancing, which pgbouncer does NOT do.
Interesting. So once clients connects to pgbouncer, it keeps the connection to clients. When a client starts a transaction, it connects to PostgreSQL(or pgpool in your case). When a client finishes the transaction, pgbouncer disconnects to PostgreSQL. Question is, what does pgbouncer deal with session span data, such as temporary tables or datestyle set by SET command? -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp _______________________________________________ Pgpool-general mailing list [email protected] http://pgfoundry.org/mailman/listinfo/pgpool-general
