2009/5/29 Grzegorz Jaśkiewicz <gryzman@xxxxxxxxx>: > On Fri, May 29, 2009 at 2:54 AM, Greg Smith <gsmith@xxxxxxxxxxxxx> 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. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
