[hackers-jp: 21] Re: [HACKERS] Experimental ARC implementation

[Tomokazu Tanaka]

　こちらのＭＬでは初めて投稿させていただきます、ミトラスの田中です。

　こちらのＭＬでこのようなＱ＆Ａ的なメールが許されるかどうか不安なのですが、
いきなり pgsql-jp に振るのもどうかと思いましたので、こちらで質問させてくださ
い。

　現在、かなり大きなテーブル（１〜２ＧＢ程度）を含むＤＢの設計をしているので
すが、頻繁に select がかかるテーブルなので、テーブル全体を shared_buffers 内
に収めてしまいたいと思っています。
　この場合２ＧＢ程度の shared_buffers を取ることになると思うのですが、この程
度の shared_buffers ですと性能が顕著に落ちてしまうものなのでしょうか？
　あまりにも顕著に性能が落ちてしまうようであれば、テーブル全体が読み込まれな
くなっても shared_buffers を減らした方が良いケースも発生するため、いくつかの
ケースを想定してベンチマークを取る必要が発生してしまいます。

　実際問題として、大きなテーブルの場合、shared_buffers にテーブルすべてが含
まれるように設定するのは現実的なことなのでしょうか？

　私自身が PostgreSQL の内部構造にうといため、判断ができずにおります。

　お知恵を拝借できれば幸いです。

　よろしくお願いいたします。

> > などと言っているように、これだけで実際に通常のpgbenchのパフォーマンス改
> > 善を見るのは大変です。実際、pgbenchはindex scanが中心なのでヒット率はか
> > なり高く、バッファ周りのパフォーマンスを調べるベンチマークとしてはふさわ
> > しくありません。
> 
> そうでもないと思いますけど．たとえば，shared_buffersが非常に大きいとき
> のパフォーマンスの劣化はpgbenchで容易に観測できます．これはおそらくバッ
> ファ管理のオーバヘッドのせいでしょう．ARCは賢いだけに，オーバヘッドが
> 大きそうなのが気になります．
> # 今度ベンチマークをしてみようかな...


----------------------------------------------------------------------------
 株式会社 ミトラス ／ Mithras Co.,LTD.
  ネットワーク開発部  田中 友和 ／ Tomokazu Tanaka <t-tanaka ＠ mithras.co.jp>
  〒112-0013  東京都 文京区 音羽 2-11-19 オトワＫＳビル ６Ｆ
  ◇ TEL: 03-5977-3255 ◇ FAX: 03-5977-3256 ◇ http://www.mithras.co.jp/ ◇

           ********** メールアドレスが変更になりました **********
             <tanaka ＠ mithras.co.jp> → <t-tanaka ＠ mithras.co.jp>
           ******************************************************