In that environment, the first PostgreSQL developers decided forking a process for each connection to the database is the safest choice.
In this post, we cover the pros and cons of PostgreSQL connection pooling.
Using a modern language library does reduce the problem somewhat - connection pooling is an essential feature of most popular database-access libraries.
It ensures ‘closed’ connections are not really closed, but returned to a pool, and ‘opening’ a new connection returns the same ‘physical connection’ back, reducing the actual forking on the PostgreSQL side.
However, all of these problems are well-discussed in the PostgreSQL community, and mitigation strategies ensure the pros of a connection pooler far exceed their cons.
In the next post, we will discuss one of the most popular connection poolers in the PostgreSQL world - PgBouncer, followed by Pgpool-II, and lastly a performance test comparison of these two PostgreSQL connection poolers in our final post of the series.