8.3でパフォーマンスは劇的に向上する - コアメンバーが語るPostgreSQLの今
http://journal.mycom.co.jp/articles/2007/06/15/postgresql/001.html
http://h50146.www5.hp.com/products/software/oe/linux/summary/reference/pdfs/hp_postgresql1.0.pdf
2005/02
Read onlyの場合，HDDの高速化およびPostgreSQLのチューニングを行ってもパフォーマンスの向上が見られませんでした (図1，2)。本評価環境では，ディスク・アクセスはボトルネックではなかったと推測します。
Read and Writeの場合，HDDの高速化あるいはトランザクション・ログの分散配置によりパフォーマンスが大幅に向上しました(図3，4，5)。本評価環境では，ディスク・アクセスがボトルネックだったと推測します。さらに，PostgreSQLのチューニングを行うことによりパフォーマンスが若干向上しました (図6)。
CPU数が多い場合，それに見合ったパフォーマンスの向上は見られませんでした。例えば図6の場合，CPU数が1の場合に比べ，CPU数が2の場合はパフォーマンスが1.8倍になりましたが，CPU数が4の場合はパフォーマンスが2.3倍にとどまりました。
CPU数が1および2の場合，データベースへの同時接続数がCPU数の2倍の時にパフォーマンスが最大となりました。Hyper Threadingを有効にしており，実質的な処理能力がCPU数の2倍であるためと推測します。一方，CPU数が4の場合，データベースへの同時接続数が6前後の時にパフォーマンスが最大となり，それ以降は低下しました。
