The following features are provided by pgpool:

One core feature of pgpool is the ability to do connection pooling. The idea is pretty much the same as the one we have outlined in the previous chapter. We want to reduce the impact of forking connections each and every time a webpage is opened. Instead, we want to keep connections open and reuse them whenever a new request comes along. Those concepts have already been discussed for pgbouncer.

In addition to pooling, pgpool provides basic replication infrastructure made explicitly to increase a system's reliability. The thing here is that pgpool uses a statement-level approach to replicate data, which has some natural restrictions users have to keep in mind (more of that later in this chapter).

One feature often requested along with replication is load balancing. pgpool offers exactly that. You can define a set of servers and use the pooler to dispatch requests to the desired database nodes. It is also capable of sending a query to the node with the lowest load.

To boost performance pgpool offers a query cache. The goal of this mechanism is to reduce the number of queries that actually make it to the real database servers—as many queries as possible should be served by the cache. We will take a closer look at this topic in this chapter.

Finally there is a feature that allows you to run parallel queries to make sure that a request can be scaled out to many different instances. We have skipped this feature in this chapter for an important reason. If you want to dispatch a query to many different nodes, it is better to go for Postgres-XC, which offers an in-core solution to the problem of query dispatching. Parsing SQL to dispatch a query is definitely not the best approach here so Postgres-XC is definitely superior in this context.