Guillaume Smet wrote > Brett Wooldridge, the creator of HikariCP [1] - a high performance > Java connection pool - is contemplating the idea to change the way > pooling is done in HikariCP and have a fixed-size pool of connections > always open. > > No maxPoolSize, no minIdle, no minPoolSize, juste a poolSize parameter > which sets the size of the pool. At application startup, all the > connections are opened and maintained by the pool throughout the life > of the application. > > The basic idea is that if you decide that your application might need > 100 connections at time, you set poolSize to 100 and HikariCP > maintains 100 connections open. > > I recall very old posts on this list where people were talking about > code paths sensitive to the number of connections open (or even > max_connections) and that it wasn't such a good idea to keep > connections open if they were not really needed. > > As a lot of scalability work has been done since this (very old) time, > I was wondering if it was still the rule of thumb or if the idea of > Brett to completely simplify the connection management is the way to > go. > > It seems that at least another pool implementation is going this way > so I thought it might be a good idea to have the opinion of the > database side of things. This way, it will be easier to take a well > informed decision. The developer, not the pool implementer, is going to ultimately decide which trade-offs to incur. Having a connection open, even if idle, consumes resources and performance no matter how minimal. Pool management does cost cycles as well so if one does not need pool management then getting rid of it is probably worthwhile to them. The question is whether you want to only meet the need of this specific user or whether you want to provide them with flexibility. If existing pool management implementations are reasonably well implemented and efficient then focusing effort on a potentially under-served use-case definitely has merit. Consider this train-of-thought: no matter how large the pool size if you are constantly keeping, say, 90% of the connections actively working then having, on average, 10% of the connections sitting idle is probably not going to be noticeable on the server and the reduction in overhead of managing a pool is typically a net positive. Now, I had no clue what percentage is actually true, or under what conditions and pool sizes it may vary, but that is a calculation that someone deciding on between managed and un-managed pools would need to make. David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Connection-pooling-Number-of-connections-tp5797025p5797030.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
