我正在使用64 GB RAM和快速RAID磁盘的专用计算机上运行PostgreSQL（8.1）服务器。 数据集本身非常庞大 – 我们有大约200GB的桌子，50-100GB的桌子，而且还在不断增长，真空在一夜之间发生，大型运营在凌晨的某个时间运行，需要一整天。
最近我们遇到了一些性能问题，比如在大型操作开始之前，真空没有及时完成，然后在今天的其余时间开始阻塞。 我们一直在试图调整我们的configuration以利用我们的资源，但是我们遇到了一些比较松散的参数，比如work_mem。 （一个实验是提高到512 MB，max_connections为150，这导致了一些问题。）
什么可能是一些很好的基准参数尝试？ 一旦我们把configuration变成一个稳定的状态，我们总是可以开始尝试更多的微调个人价值观，但是我们不确定我们的需求与这种事情的标准build议有什么不同。
编辑：我在评论中回答了这个问题，但为了使之正式，我们正在制定一个更长远的计划，包括分区以及其他一些重构任务，但是现在我们正在尝试充分利用我们所拥有的东西。 我正在寻找更多的技巧，“32MB的work_mem设置可能会为你提供相当好的服务，但是你可能看不到64MB以上的改进。”
PostgreSQL 8.1是相当古老的，它已经达到了EOL的时间（见PostgreSQL发布支持政策 ）。 我认为新版本（如9.0）有更好的性能（尤其是更好的吸尘），在我看来，这是第一步（当然postgresql.conf和内核/ ulimit设置也很重要）。
在PostgreSQL文档中，为这样大的（和不断增长的）表格描述了分区方法。 这可能是有用的解决scheme。
从http://www.day32.com/MySQL/Meetup/Presentations/postgresql_partitioning_short.pdf
当表的大小超过物理内存时，对表进行分区通常是有价值的。
考虑到大量的数据和不断增长的事实，如果您只使用一台服务器，从长远angular度看，没有任何调整是足够好的。 您应该开始考虑将其中一些表移动到其他服务器，并在可能时进行分片（以保持可扩展性）。 其中一些甚至可能适合云服务（即SimpleDB）。 无论如何，我不知道是否分片或NoSQL解决scheme可能适合您的需求，因为我不知道您的数据，但在很多情况下，与一个好的devise，它确实。 临时解决scheme可能是使用一些读取从属和/或memcached农场，以防万一在白天使用时出现性能问题。