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.
