DBS为什么不自动调整/调整缓冲区大小？
不确定是否没有DBS，以及这是否确实是一个有用的功能，但是： 有许多关于如何通过调整缓冲区大小来加速数据库操作的建议。一个例子是将Open Street Map数据（星球文件）导入到Postgres实例中。有一个名为osm2pgsql（http://wiki.openstreetmap.org/wiki/Osm2pgsql）的工具用于此目的，并且还提供了一个指导，以便为此调整特定的缓冲区参数。 在导入的最后一步，数据库正在创建索引，并且（根据我在阅读文档时的理解）将从巨大的maintenance_work_mem中受益，而在正常操作期间，这不会太有用。 这个线程http://www.mail-archive.com/[email protected]/msg119245.html相反表明一个很大的maintenance_work_mem在创建最终索引期间没有太多意义。 理想情况下，DBS应该知道什么样的缓冲区大小组合可以让利润最大，因为缓冲区总容量有限。 那么，是否有一些很好的理由说明为什么没有内置的启发式方法能够根据当前任务自动调整缓冲区大小？DBS为什么不自动调整/调整缓冲区大小？
的问题是相同的，与任何预测软件。仅仅因为历史上发生的事情并不意味着它会再次发生。此外，您需要完成一项任务，以便全面分析如何更有效地完成它。问题是下一个任务不一定像以前完成的任务。因此，如果您的导入例程需要8GB内存才能完成，那么为每个只读用户分配8GB内存是否合理？反过来也不行。
在离开这个决定人类，数据库会表现出不适合用来所有情况下的性能特点，但作为回报，让我们（人类）单独优化每一种情况下（如果喜欢）。
另一个重要的方面是大多数人/公司在变化但可能更好的水平上看重可靠和稳定的水平。成本高昂并不像成本差异大。这当然不是一直如此，因为整个公司都是基于这个事实，偶尔达到1％。
现代数据库已经做出一些努力来适应自己提出的任务，比如越来越多的sofisticated查询优化。至少Oracle可以选择跟踪影响优化器决策的一些措施（单块读取的成本将随当前负载而变化）。
我猜测将是非常艰难向右自适应手段得到的旋钮。首先，您必须向机器查询很多未知数，比如它有多少内存可用 - 还有未知“您希望在机器上运行多少”。
除非是，通过设置只有max_mem_usage参数，问题是如何使这
- 很好地适应最典型负载的系统。
- 有些负载不会有奇怪的病理问题。
- 是有点可理解的代码没有错误。
对于PostgreSQL然而，答案也可能是
- 没有人写的，因为还没有其他的东西被认为是更重要的。
- 你还没写。