[pgsql-jp: 36073] Re: 検索系システムのパフォーマンスについて

[Kiyoshi Mizuno]

水野です。

> -----Original Message-----
> BufMgrLock の仕様はほとんど知らないのですが、タイトルにあるような
> 検索系システムにも大きく影響するものなのでしょうか。
> 検索系システムの場合、全体のデータ量、キャッシュ量、ヒット率の関係
> がパフォーマンスを左右するのでは、と思ったのですが。

テーブルを総ナメする場合はメモリ量とディスクＩ／Ｏが効くと思います。
で、例によって該当テーブル全体を格納するのに必要と思われる
メモリサイズを計算してみると、
　レコード数：110,000件
　カラム数／レコード：１００
　カラムサイズ：１０byte/column（仮定）
　＝約１１０MB
となりました。

一方PostgreSQLの設定では
　shared_buffers = 4096
　１バッファ＝8192bytes（とマニュアルに書いてあった）
　＝約３２MB
となりますので、select * from table; / select count(*) from table;
を行うとバッファが不足するだろうと思います。
＃「SELECT COUNT(*)」ではレコード全体をキャッシュに読んじゃいますよね？

7.4.6のマニュアルではshared_buffersの項にバッファのブロックサイズを
変える事が可能（サーバを構築する時にBLCKSZを変更できる）と書いて
あるので、サーバ再構築が可能ならばshared_buffersを倍に、BLCKSZも
倍に設定すれば合計して約１２８MBになり、select * from table;しても
全データがキャッシュに収まるようになるのではないかと思われます。
再構築が不可能ならばshared_buffersを４倍（16,000程度）にして
回避するのでしょうか。ただ、

> 谷田です。
（中略）
> このような考え方では商用DBなどでは普通ですが、残念ながらPostgreSQLではう
> まくいくとは限らないということがよく知られています。というのも内部的な
> ロック(BufMgrLock)とかのつくりの関係で、キャッシュ量を増やせば増やすほど
> パフォーマンスが低下してしまうのです。なので、PostgreSQLのバッファはたと
> えば1000〜10000程度にするのが定石です。なのでこの数字だけ見て少なすぎる
> ということはないでしょう
> 
> 例外はキャッシュに収めておかなければならない、頻繁にアクセスするデータが
> 多すぎて、キャッシュ率が極端に低くディスクI/Oがボトルネックのパターンで、
> このような場合だとバッファを増やしてパフォーマンスが増加することがありま
> す。

という事ですので、バッファ追加でどの程度効果が出るかは微妙ですね。
（やってみないと分からない）

> こんにちは、木村といいます。
（中略）
> 検索用のインデックステーブルを検索パターン合わせて幾つか
> 作った方が良いと思います。

こっちの方が現実的かな？