Re: Max_connections limit

On Wed, Jun 26, 2019 at 5:16 AM Hervé Schweitzer (HER) <
herve(dot)schweitzer(at)dbi-services(dot)com> 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.