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

[Tomokazu Tanaka]

　お世話になっております、ミトラスの田中です。

　2003年11月07日 09時25分にいただいた、
　「[hackers-jp: 22] Re: [HACKERS] Experimental ARC implementation」への返信です。

> むしろpgsql-jpの方が良いのではないかと思いますが・・・

　内容的には完全にpgsql-jpだなとは思ったのですが、石井さんのメールを見て思い
ついちゃったので、骨髄反射でこちらにメールしてしまいました。すみません。

> > 　現在、かなり大きなテーブル（１〜２ＧＢ程度）を含むＤＢの設計をしているので
> > すが、頻繁に select がかかるテーブルなので、テーブル全体を shared_buffers 内
> > に収めてしまいたいと思っています。
> 
> 　まずこの部分からしてすでに間違っているように思います。
> 
> 　頻繁にselectがかかるといっても、その頻度はどの程度か、によるでしょう。
> たとえばpgbench -S(検索のみ)の場合のaccountsテーブルなどはまさにこれ（頻
> 繁にselectがかかる巨大テーブル）に該当しますが、さほどバッファを確保せず
> ともindexを使って軽く100tps以上の性能を確保しています。

　最近、PostgreSQL専用に使うサーバーには４ＧＢメモリを積むことが多いんですが、
shared_buffers を増やすか、sort_mem にまわすか、max_connections を増やすか、
ＯＳに任せてディスクキャッシュにでも使ってもらうかくらいしか思いつかないので、
shared_buffers を増やしてテーブル全体をオンメモリにしてしまうのが一番効率が
良いのかなぁと考えたんです。

　実際のところはテーブル設計やクエリーの傾向などにもよるのでしょうが、
shared_buffers は多ければ多いほどいいと思っていた自分にとってはバッファ管理
のオーバーヘッドでパフォーマンスの劣化が起こるというのは盲点でしたので、良い
勉強をさせていただきました。

　今後は shared_buffers の値をいろいろといじってみて、できるだけ実環境に近い
ベンチマークを取ってみようと思います。

----------------------------------------------------------------------------
 株式会社 ミトラス ／ 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>
           ******************************************************