PostgreSQL 为什么接受大量连接到数据库需要连接池 （这是一篇2020年8月4日我写的文章，分析为什么，根本上也没有如某些diss postgresql 连接数不能太高问题非常严重的人所说的影响严重，实际上针对PostgreSQL 连接的问题，还真有一个可以说一下的，但鲜有人提到）
正文
————————————————————————————
最近在群里对于PostgreSQL的问题点就没有停止过，前两天PostgreSQL的老问题连接数不能过高的问题，又成为刺向PostgreSQL的一根芒刺。作为一个数据库渣男，大部分数据库都玩过了，的确从其他的数据库DBA的角度来看，PostgreSQL的确和其他的数据库在这里是不太一样，有些特殊的要求，注意我这里用的不太一样，不太一样不证明这就是一个缺陷，缺点，或者痛点。
其实从另一个角度上来说，我到觉得这是一件好事，我们来分析一下。从应用开发的角度来说，应用是可以横向扩展的，这在业内不是一个难题，无状态嘛，但在整体应用程序设计中，最重要的点就在数据库，数据库一直是应用程序设计中的一个瓶颈点，所以后来出现了分布式数据库，Tidb, OceanBase 等数据库产品，来从根本解决这个问题。
当然今天讨论的不是这个话题，咱们回到刚才的话题，PostgreSQL的连接数到底是不是他的弱点，我个人觉得，不是，我是从应用开发的角度来看这个问题的。
比如，MySQL可以支持6000的连接数，这个数是什么数，max_connections，最大连接数，这个数是active_sessions的,根据我们的工作经验，实际上大部分数据库的问题在active_sessions，而不是我们提到的max_connections。所以我们标定这个问题清晰了，解决问题就可以了。而不是抓住一个值，来去说明某个实际上并不重要的问题。终究咱们要通过实际情况和需求来去评判某个数据库的优良，而不是一个参数抓住就往死里按，这对解决实际问题是没有意义的。
那么核心的问题是active_sessions 的问题，这个问题对于PG，SQL SERVER, MySQL, Oracle, Polardb ,MongoDB 这都是一个概念，是否有充足的资源来去满足活跃的链接的访问，此时要比拼的就是 IOPS , CPU, Memory, 系统整体的性能，以及访问的方式是什么OLTP OR OLAP 等。
idle 连接数过多导致的问题，这不光是在PG，其他的数据库也存在类似的问题，只不过可能有人又要拿出来，进程和线程的模式来说事了。
在应用程序都在大量使用连接池的,JAVA自己的连接池，其中有一个目的与PostgreSQL的pgbouncer的功能是类似的，就是链接复用，只不过JAVA的连接池的功能没有pgbouncer在链接复用上的功能强而已。
从这里可以得出一些结论
1 从应用开发的角度来说，连接数高并不是一个好事，对于应用程序本身也是，所以应用程序本身有程序的连接池，来进行访问进程的复用。
2 大量idle的连接本身对于内存的开销尤其是数据库方面的开销是有负担的，超过内存的owner回导致OOM，这在任何数据库里面都一样，甚至有些数据库本身在这方面的内存管理能力不太好，导致内存溢出的问题。
3 讨论一个数据库可以进行的max_connections数据量多，并不是衡量一个数据库能力的高低的关键维度，甚至可能都不是一个维度。
4 PostgreSQL 本身有自己解决问题的方式，后期可能在PostgreSQL 快速迭代的情况下，这些问题可能会逐步解决，甚至和Oracle 类似有自己内部解决此类问题的方式。
综上所述，一个成熟的数据库管理人员，可以更加关注active_sesssion在不同的数据库中的表现，相信PostgreSQL 不会让您在这个位置失望。
最后说一个人家亲口和我说的事情，某云数据库架构师去某金融企业做回访，提到MySQL类数据库产品的一些新功能想介绍一下，这个金融系统的数据库负责人说，不太想听这个，能说说PostgreSQL类的产品吗，他比较想听。
Austindatabases 公众号，主要围绕数据库技术（PostgreSQL, MySQL, Mongodb, Redis, SqlServer，PolarDB, Oceanbase 等）和职业发展，国外数据库大会音译,国外大型IT信息类网站文章翻译，等，希望能和您共同发展。
