2009/5/29 Scott Mead <scott(dot)lists(at)enterprisedb(dot)com>
> 2009/5/29 Greg Smith <gsmith(at)gregsmith(dot)com>
>> 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:
> Exactly, here's the thing, if you have an open transaction somewhere to
> the system, there may be a REALLY good reason for it. If you're app or dev
> team is keeping those open, it's very possible that 'reaping' them is going
> to cause some kind of data integrity issue in your database. I would
> investigate the application and make sure that everything is actually
> rolling back or commiting. If you're using an ORM, make sure that it's
> using autocommit, this usually makes the issue go away.
> As to the context switching point -- A connection pooler is what you need.
> Why make your database server dedicate cycles to having to figure out who
> gets on the CPU next? Why not lower the number of connections, and let a
> connection pool decide what to use. That usually helps with your open
> transactions too (if they indeed are just abandoned by the application).
>> 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.
> This sounds like a dirty plug (sorry sorry sorry, it's for informative
> purposes only)...
> Open Source:
> One-Click installers : No connection pool bundled (will be
> included in 8.4 one-click installers)
> PostgresPlus Standard Edition : pgBouncer is bundled
> PostgresPlus Advanced Server: pgBouncer is bundled
> That being said, the well known connection pools for postgres are pretty
> small and easy to download / build / configure and get up and running.
Which is better and more complete, which have more features?
What you recommend? pgbouncer or pgpool?
In response to
pgsql-performance by date
|Next:||From: Scott Mead||Date: 2009-05-29 19:50:48|
|Subject: Re: Scalability in postgres|
|Previous:||From: Scott Mead||Date: 2009-05-29 19:08:43|
|Subject: Re: Unexpected query plan results|