我在Centos 5上有一个4GB的内存和PostgreSQL 9.0.3的服务器。我使用pgbench和pgbench-tools来使用两个pgbench-tools查询来testing性能： select和tpc-b 。
使用postgresql.conf默认设置并使用select查询，我得到以下结果：
比例：1,10,100,1000。
每秒事务数：10000，8800，7500，100。
（该表的logging数是比例* 100000）
我增加了选项shared_buffer到256MB（以前是32 MB），我得到以下结果：
比例：1,10,100,1000。
每秒事务数：10000，8000，3200，30
与第一次testing相比，为什么在第二个基准testing中testing结果为100或更高时性能如此之低 ？ 我唯一做的就是增加内存。
当你增加shared_buffers的时候，唯一一个让pgbench变得更慢的是一个叫做assertion checking的debugging选项。 如果你在psql中这样做：
show debug_assertions;
现在，你的构build有这个问题，你看到的结果是预期的。 你需要一个新的安装，没有启用断言debugging，使其消失。
否则，如果你不是这样做了一次以上，我不会确定这里的原因是shared_buffers变化。 举一个例子，如果autovacuum碰巧运行在你的大型数据库正在运行的地方，它会减慢testing结果。 开始testing的检查点也将开始。 closures自动清理以将其从testing中清除，并打开log_checkpoints以查看是否有干扰。
第三种可能性，我几乎可以确定你在某种程度上受到了影响，因为在磁盘上移动的东西可能会导致结果下降50％。 磁盘的早期部分和后面的部分相比速度要快一倍，而且当你重复运行pgbench时，数据会随着时间移动到较慢的部分。 我最终重build整个文件系统，以获得可重复的结果，只有这样才能确保你从驱动器上的同一点开始。 这不会影响较小规模的结果，因为这些都适合RAM。
触摸configuration参数后，当我看到性能改变时，我总是再次尝试原始configuration，以确保是原因。 我常常惊讶地发现，每次运行testing的速度都会变慢，而这种磁盘位置的速度差异就是这个问题的一个来源。