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.
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.
