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

Re: Scalability in postgres

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com>
Cc: 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 17:37:54
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Fri, 29 May 2009, Grzegorz Ja?kiewicz wrote:

> if it is implemented somewhere else better, shouldn't that make it
> obvious that postgresql should solve it internally ?

Opening a database connection has some overhead to it that can't go away 
without losing *something* in the process that you want the database to 
handle.  That something usually impacts either security or crash-safety. 
This is why every serious database product in the world suggests using 
connection pooling; examples:

The only difference here is that some of the commercial products bundle 
the connection pooler into the main program.  In most cases, you're still 
stuck with configuring a second piece of software, the only difference is 
that said software might already be installed for you by the big DB 
installer. Since this project isn't in the business of bundling every 
piece of additional software that might be useful with the database, it's 
never going to make it into the core code when it works quite happily 
outside of it.  The best you could hope for is that people who bundle 
large chunks of other stuff along with their PostgreSQL installer, like 
Enterprise DB does, might include one of the popular poolers one day.

And that's how we got to here.  There are plenty of PostgreSQL problems 
one might run into that there are no usable solutions to, but that other 
database vendors have already solved nicely.  From a pragmatic standpoint, 
I'd rather see people work on those, rather than try and forge new ground 
on a problem everyone else in the industry has failed to solve.

* Greg Smith gsmith(at)gregsmith(dot)com Baltimore, MD

In response to


pgsql-performance by date

Next:From: FabrixDate: 2009-05-29 17:49:00
Subject: Re: Scalability in postgres
Previous:From: Dave DutcherDate: 2009-05-29 17:30:38
Subject: Re: Unexpected query plan results

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