On Wed, Jun 26, 2019 at 5:16 AM Hervé Schweitzer (HER) <herve.schweitzer@xxxxxxxxxxxxxxxx> wrote:
You now that Postgres don’t have any shared_pool as Oracle, and the session information ( execution plan, etc..) are only available for the current session. Therefore I also highly recommend to us a connection poll as Laurent wrote, in order to have higher chance that some stuff is already cached in the shared session available.
Regards
Herve
The most popular stand-alone connection pooler for PostgreSQL is the oddly named "pgbouncer": https://wiki.postgresql.org/wiki/PgBouncer
There are others, of course.
PgPool is also very popular: https://www.pgpool.net/mediawiki/index.php/Main_Page
Some applications can also manage a connection pool efficiently entirely within the application itself.
Configuring the maximum number of concurrent connections your database supports incurs significant overhead in the running database. New connections and disconnections also have a high overhead as they occur. By moving the connecting/disconnecting logic to a connection pooler you remove a lot of overhead and load from the database - letting it focus on the important stuff -- your queries.
It is amazing how many fewer actual connections you need to the database when you configure a pooler. Most connections from applications and users are idle most of the time. Even on busy web servers. They just keep that pathway open in case they need to run a query to save on the overhead of having to open a new one every time. By using a pooler you only need to configure connections for the number of concurrent _queries_ rather than concurrent application and user open but idle connections.
