[Pgpool-general] PgPool install, Part Deux

Jaume Sabater jsabater at gmail.com
Mon Jul 13 10:51:11 UTC 2009


On Wed, Jul 8, 2009 at 11:58 AM, J. Carlos Muro<murojc at gmail.com> wrote:

> The meaning of "ready for production environments" somehow (or "some much")
> depends on your requirements.. I don't want to go into deep discussion with
> it as we will find no end. But, we can make the question in another
> direction: is you production environment ready for pgpool?

Now that is something everyone reading this list should have in mind.

When I was first asked to setup a prototype of a PostgreSQL cluster
for a customer, first thing I asked was "what type of usage are you
doing to do from it". Reply was "mostly SELECT, few INSERT and
UPDATE". I forced them to reprogram a few stored procedures and a bit
of their business logic so that they didn't use NOW() functions,
SERIAL types, and similar.

Result: awesome performance for a system where pgpool-II fits
perfectly (replication plus load balance). Does that mean pgpool-II
fits correctly/perfectly always? No, it does not.

>From the usage of pgpool-II I've done since October 2008, I've come to
the conclusion that it's a very good solution if you are using an ORM,
say using Alchemy, JPOX, etc. Shall you have a team of developers that
send hand-made, complex SQL queries to the cluster, then you will have
to review the application to see whether it fits into pgpool-II
requirements (or scope, or target application).

In the end, pgpool-II replicates at SQL level. If you understand what
that means, you'll automatically understand when you can use pgpool-II
and when you should not use it. pgpool-II is a very good solution for
a number of problems and situation, not for EVERY situation.

-- 
Jaume Sabater
http://linuxsilo.net/

"Ubi sapientas ibi libertas"


More information about the Pgpool-general mailing list