Sethu Prasad wrote > Reaching the maxPoolSize from the minPoolSize means creating the > connections at the crucial moment where the client application is in the > desperate need of completing an important query/transaction which the > primary responsibility since it cannot hold the data collected. One query is slowed down a little in the unusual situation where not enough pooled connections are available. To fix that you want to slow down the entire server all of the time? Really? And even if this is sometimes the best option your assertion is unqualified so do you really think this is best for everyone, always? I think it is good to give developers options but if your situation is 10 / 100 then a fixed 100 connection pool is probably not the best configuration. The question I'd ask is if you are developing a new driver what problem and use-case are you trying to accommodate? For those in the general case a resizing pool is probably the best bet. It will usually stabilize at typical volume so that an optimum number of connections are maintained while still allowing for some expansion in times of excess demand. A fixed size pool would be something an experienced user would decide they need based upon their usage patterns and need to eke out every last bit of performance in the extremes situations while only trading a little bit of performance when the connections are not maxed out. David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Connection-pooling-Number-of-connections-tp5797025p5797061.html Sent from the PostgreSQL - performance mailing list archive at Nabble.com. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
