On Fri, 25 Oct 2002, Bruce Momjian wrote: > Tom Lane wrote: > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > Basically, total connections is to be set larger than you think you will > > > ever need, while you expect per-db to be hit, and if something keeps > > > trying to connect and failing, we may get very bad connection > > > performance for other backends. > > > > Hmm, I see your point. A per-db limit *could* be useful even if it's > > set high enough that you don't expect it to be hit ... but most likely > > people would try to use it in a way that it wouldn't be very efficient > > compared to a client-side solution. > > The only way to do it would be, after a few hits of the limit, to start > delaying the connection rejections so you don't get hammered. It could > be done, but even then, I am not sure if it would be optimal.
Note that I don't believe there is an "optimal solution" for this ... but in an environment where there are several clients connecting to several different databases, the ability for one client to starve out the others is actually very real ... ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
