2009/5/29 Grzegorz Jaśkiewicz <gryzman@gmail.com>:
> On Fri, May 29, 2009 at 2:54 AM, Greg Smith <gsmith@gregsmith.com> wrote:
>
>> The PostgreSQL connection handler is known to be bad at handling high
>> connection loads compared to the popular pooling projects, so you really
>> shouldn't throw this problem at it. While kernel problems stack on top of
>> that, you really shouldn't start at kernel fixes; nail the really
>> fundamental and obvious problem first.
>
> if it is implemented somewhere else better, shouldn't that make it
> obvious that postgresql should solve it internally ? It is really
> annoying to hear all the time that you should add additional path of
> execution to already complex stack, and rely on more code to handle
> something (poolers).
Well Oracle I know suffers from the same issue under any real load.
On a large transactional system where I last worked, we had to keep
the live connections to the db down to under 100 to keep it running
well. The complexity has to go somewhere, and poolers are usually a
better choice.