Re: Scalability in postgres

From: Scott Mead <scott(dot)lists(at)enterprisedb(dot)com>
To: Fabrix <fabrixio1(at)gmail(dot)com>
Cc: Greg Smith <gsmith(at)gregsmith(dot)com>, Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com>, Flavio Henrique Araque Gurgel <flavio(at)4linux(dot)com(dot)br>, pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Scalability in postgres
Date: 2009-05-29 19:50:48
Message-ID: d3ab2ec80905291250r6c1ff38ei75c9b36ff66879c@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Fri, May 29, 2009 at 3:45 PM, Fabrix <fabrixio1(at)gmail(dot)com> wrote:

>
> Which is better and more complete, which have more features?
> What you recommend? pgbouncer or pgpool?
>
>>
In your case, where you're looking to just get the connection overhead
off of the machine, pgBouncer is probably going to be more efficient. It's
small and very lightweight, and you don't have to worry about a lot of extra
features. It is a '... to the wall' connection pool.

pgPool is definitely more feature-full, but honestly, you probably don't
need the ability (at least now) to balance selects / against replicated
servers, or have the pooler do a write to multiple servers for H/A. Both
these things would take more time to implement.

pgPool is real an all-around H/A / scalability architecture e decision
whereas pgBouncer is a nice, lightweight and quick way to:

*) Lower the number of connections to the dbserver
*) Avoid connect / disconnect overhead

--Scott

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Anne Rosset 2009-05-29 21:31:57 Re: Unexpected query plan results
Previous Message Fabrix 2009-05-29 19:45:48 Re: Scalability in postgres