Skip site navigation (1) Skip section navigation (2)

Re: Scalability in postgres

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com>
Cc: Greg Smith <gsmith(at)gregsmith(dot)com>, Flavio Henrique Araque Gurgel <flavio(at)4linux(dot)com(dot)br>, Fabrix <fabrixio1(at)gmail(dot)com>, pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Scalability in postgres
Date: 2009-05-29 12:10:44
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
2009/5/29 Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com>:
> On Fri, May 29, 2009 at 2:54 AM, Greg Smith <gsmith(at)gregsmith(dot)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.

In response to

pgsql-performance by date

Next:From: Scott MarloweDate: 2009-05-29 12:11:10
Subject: Re: Scalability in postgres
Previous:From: Grzegorz JaśkiewiczDate: 2009-05-29 10:45:02
Subject: Re: Scalability in postgres

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group