PostgreSQL does not highly prioritize making the act of connecting to the database one that happens quickly. Each connection requires starting a new process to talk to the client, a fairly expensive operation, and things such as the pg_hba.conf authentication implementation are optimized for security and flexibility even if this comes at the expense of speed. The presumption is that users will run things for a long time relative to how long it takes to connect.
When this isn't true, which can be the case for web applications in particular, connection pooling is one approach to reduce this overhead. The connection pool sits between your application and the database. It makes a fixed number of connections to the database, typically under 100, and keeps them open all the time. As incoming requests come in, those connections in the pool are re-used. The DISCARD...
