我在一台专用机器上使用 PostgreSQL (8.1) 服务器，该机器有 64 GB 的 RAM 和一个快速 RAID 磁盘。数据集本身非常庞大 - 我们有几个大约 200 GB 的表，更多在 50-100 GB 范围内，并且它不断增长，包括夜间的清理、清晨某个时间运行的大型操作以及全天按需运行的小型操作。
我们最近遇到了一些性能问题，比如，在大型操作开始之前，清理工作没有及时完成，然后开始阻塞一整天。我们一直在尝试调整配置以充分利用我们的资源，但我们在一些定义较为宽松的参数（如 work_mem）方面遇到了麻烦。（一个实验是将其提高到 512 MB，并将 max_connections 设置为 150，结果导致了一些问题。）
哪些基准参数值得尝试？一旦配置进入稳定状态，我们就可以开始尝试微调各个值，但我们不确定我们的需求与此类标准建议有何不同。
编辑：我在评论中回答了这个问题，但为了正式宣布，我们正在制定一个更长期的计划，其中包括分区以及其他一些重新架构任务，但现在，我们正在努力充分利用我们现有的资源。我正在寻找更类似于“32MB 的 work_mem 设置可能对您来说相当好，但您可能不会看到超过 64MB 的太多改进”的提示。
答案1
PostgreSQL 8.1 已经很老了，已经到达了 EOL 时间（见PostgreSQL 版本支持政策)。我认为较新的版本（例如 9.0）具有更好的性能（尤其是更好的清理功能），并且在我看来这是第一步（当然 postgresql.conf 和可能的内核/ulimit 设置也很重要）。
在 PostgreSQL 文档中有分割这种方法适用于如此大的（并且不断增长的）表格。这可能是一种有用的解决方案。
从http://www.day32.com/MySQL/Meetup/Presentations/postgresql_partitioning_short.pdf
通常，只有当表的大小超出物理内存时，对表进行分区才值得。
答案2
鉴于数据量巨大且数据不断增长，如果您继续只使用一台服务器，从长远来看，任何调整都不够好。您应该开始考虑将一些表移动到其他服务器，并在可能的情况下进行分片（以保持可扩展性）。其中一些甚至可能适合云服务（即 SimpleDB）。无论如何，我不知道分片或 NoSQL 解决方案是否适合您的需求，因为我不知道您的数据，但在许多情况下，如果设计良好，它确实可以满足您的需求。临时解决方案可能是使用一些读取从属服务器和/或 memcached 场，以防您在白天使用时遇到性能问题。