PgBouncer does not need to see full network packets at once, so memory usage is very down and limited.
Several levels of brutality when rotating connections occur.
In session pooling, when the client connects, a server connection will be assigned to it for the whole duration it stays connected. When client disconnects, the server connection will be put back into pool.
In transaction pooling, a server connection is assigned to client only during a transaction. When PgBouncer notices that transaction is over, the server will be put back into pool. This is a hack as it breaks application expectations of backend connection. The developer can use it only when application cooperates with such usage by not using features that can break. See the table below for breaking features.
In statement pooling (most aggressive method), multi-statement transactions are disallowed. This is meant to enforce "autocommit" mode on client, mostly targeted for PL/Proxy.
Here are some key features of "PgBouncer":
· Statement pooling
· Transaction pooling
· Session pooling
· Low memory requirements (2k per connection by default).
· It is not tied to one backend server, the destination databases can reside on different hosts.
· Supports online reconfiguration for most of the settings.
· Supports online restart/upgrade without dropping client connections.
· Supports protocol V3 only, so backend version must be >= 7.4.
Requirements:
· PostgreSQL
What's New in This Release: [ read full changelog ]
· Improved DNS invalidation, KILL command, and more.
Find us on Google+
