Hi Tom, On Fri, Mar 21, 2014 at 5:17 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > It will cost you, in ProcArray scans for example. But lots-of-idle- > connections is exactly what a pooler is supposed to prevent. If you have > a server that can handle say 10 active queries, you should have a pool > size of 10, not 100. (If you have a server that can actually handle > 100 active queries, I'd like to have your IT budget.) > > The proposed design sounds fairly reasonable to me, as long as users are > clear on how to set the pool size --- and in particular that bigger is > not better. Clueless users could definitely shoot themselves in the > foot, though. Yeah, well. My understanding of what happened on the field is that people usually set the pool size limit quite high because they don't want to experience connection starvation even if there is a temporary slowdown of their application/database. Is the overhead of having 100 connections open noticeable or is it better to not have them but not so bad to have them? Thanks. -- Guillaume -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
