DBのパフォーマンスにはさまざまな因子が影響を与えますが、

SQLや、DBのパフォーマンスを見るならば、
まず、あくまで実行プランが同じかどうか、
実行プランや、部分的・全体的なコスト、時間が異なる箇所がないかどうかの比較調査から初める

設定値、データ量、データ内容が関わっている可能性が出てきます。
またデータ量、データ内容、によってanalyzeの結果が変わってきたりする。

vacuumが適切になされているかに左右される。

postgresqlの場合はexplain analyze verboseでいろいろな情報が見られるので、
実際の実行時間や、メモリ・ディスクの使われ方などと合わせて比較してみる。

 

キャッシュについても少し触れると、キャッシュが効いているかどうか、キャッシュの大きさを決める値はshared_buffersです。

この値が、実行速度に与える影響はLinuxにおいてはそう大きくありません。

effective_cache_sizeとは何か

カーネルや PostgeSQL の共有バッファで、PostgreSQL が使用するバッファ領域の大きさの推定値です。
effective_cache_size * 8192 がバイトに換算した値になります（デフォルト値は8MB）。
参照するテーブルが effective_cache_size の範囲内に収まっているとオプティマイザは積極的にインデックスを使うようになります。

effective_cache_sizeが関係している可能性は0ではないですが、
「それはキャッシュが効いていない」などという理由とはまったく別の理由です。
これは実際のキャッシュの大きさを決めるためのパラメータではありません。

その他、関係してくるのが
checkpoint_segments
commit_delay
max_connections
wal_buffers
work_mem

 

参考にしたサイト

http://tdoc.info/blog/2012/07/09/postgres_tuning.html

http://php.y-110.net/wiki/?PostgreSQL%A1%A7%A5%C1%A5%E5%A1%BC%A5%CB%A5%F3%A5%B0%B4%AA%BD%EA