Re: Connection pooling - Number of connections
От | Guillaume Smet |
---|---|
Тема | Re: Connection pooling - Number of connections |
Дата | |
Msg-id | CALt0+o8BffN73JzsEQRas1zhbRXCq=EmnMoEH9OcDqsAYEHfNg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Connection pooling - Number of connections (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Connection pooling - Number of connections
|
Список | pgsql-performance |
Hi Tom, On Fri, Mar 21, 2014 at 5:17 PM, Tom Lane <tgl@sss.pgh.pa.us> 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
В списке pgsql-performance по дате отправления: