来自 PostgreSQL 文档：
-
为了获得最佳吞吐量，活动连接的数量应该接近 ((core_count * 2) + Effective_spindle_count)
调整你的 PostgreSQL 服务器 -> max_connections
一般来说，好的硬件上的 PostgreSQL 可以支持几百个连接。
对我来说——不是一个经验丰富的 DBA——这里的某个地方存在差异，尤其是在查看一些 DB 即服务提供商的产品时。
例如，此时 Amazon RDS 最大的机器 (db.r3.8xlarge) 有 32 个 vCPU，根据第一个公式，在给定许多磁盘的情况下，池中的 100 个连接可能会设法以最佳方式运行。第二个公式中的“几百个连接”不是很糟糕吗？
更极端的是另一家 DBaaS 提供商的差异，他们提出了一个具有 500 个并发连接的 2 核服务器。这怎么可能运作良好？
如果我有什么误解，请告诉我。非常感谢！
“可以支持”！=“最佳吞吐量”。
您可以使用大量连接，但速度较慢。
如果您使用更少的连接和排队工作，您可以在更短的时间内完成相同数量的工作。
他们要么在事务池模式下使用像 PgBouncer 这样的连接池前端，要么无法正常工作。
人们喜欢大数字，所以他们会给你大数字。
他们这样做实际上是在损害性能。PostgreSQL 有一些成本与 线性扩展
max_connections，因此即使不使用连接，它仍然会对性能产生影响。此外，即使是空闲连接也会产生一些额外的内务管理成本。
如果连接正在积极工作，那么您还会争用系统资源和内部锁。
我经常遇到遇到 PostgreSQL 性能问题的人——他们试图通过在应用程序中添加更多连接、更多工作人员等来解决这些问题。尤其是运行排队系统的人。很难说服他们减少工人数量会使系统运行得更快，而他们最初的性能问题源于工人数量过多。
许多应用程序的连接规则很差，即使在不使用连接时也保持连接打开。
设置高连接限制是针对这些应用程序的廉价保险。在某些情况发生变化并且应用程序决定积极使用所有这些连接之前，保险变得非常昂贵。
问题中比较的两种说法之间的一个重要区别是，第一种说法是任何时候活动连接数量的粗略公式。第二个声明是针对您为 Postgres 将接受的最大允许值设置的设置。这是两个不同的东西。
当您返回阅读Optimal Database Connection Pool Size文章时，您会发现它建议您在客户端设置活动连接池，而不是在服务器端。他们还建议您在max_connections值中保留足够的容量以容纳固定连接，例如手动客户端活动和管理活动。您不想将 max_connections 设置为工作人员的活动连接限制，否则您可能无法在需要时使用 psql！