pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: David Johnston <polobo@yahoo.com>
To: pgsql-performance@postgresql.org
Subject: Re: Connection pooling - Number of connections
Date: Fri, 21 Mar 2014 11:41:05 -0700 (PDT)
Message-ID: <1395427265559-5797061.post@n5.nabble.com> (raw)
In-Reply-To: <CAK=WF3SqysgOe=E8Sd60+bGy6zc-8jXyHgFMj0m0Tj6FBc3afw@mail.gmail.com>
References: <CALt0+o-5wuUA_1TjNTb+xP43=Ua6ge5PuyOo51QcmDM6cnm9-g@mail.gmail.com>
	<1395416983206-5797030.post@n5.nabble.com>
	<CALt0+o-W_rTy2M+5rHb61KksSBrCncOT_4=ctf3e_MKYTTVTdA@mail.gmail.com>
	<18360.1395418662@sss.pgh.pa.us>
	<CAK=WF3SqysgOe=E8Sd60+bGy6zc-8jXyHgFMj0m0Tj6FBc3afw@mail.gmail.com>
List-Unsubscribe:  <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>

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.h...
Sent from the PostgreSQL - performance mailing list archive at Nabble.com.


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance



view thread (18+ messages)  latest in thread

Message-ID: <1395427265559-5797061.post@n5.nabble.com>
Permalink:  ../1395427265559-5797061.post@n5.nabble.com/
Also on:    postgresql.org/message-id/1395427265559-5797061.post@n5.nabble.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: polobo@yahoo.com
  Subject: Re: Connection pooling - Number of connections
  In-Reply-To: <1395427265559-5797061.post@n5.nabble.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox