[pgsql-jp: 29334] Re: パフォーマンス向上策

[Tsunehisa Kazawa]

こんにちは。加澤と申します。

Makoto Komatsu wrote:
> PostgreSQLも少々クセがあるみたいで、理論どおりではああなんだけど、実際には
> こっちがいいよ、みたいなことが多々あるもんですよ。
> そのへんは経験と割り切りが肝要。

かつて PostgreSQL をかなりヘビーに (daily で 600 万 trans、ピーク時
には 150 trans/sec 程度の OLTP 系処理) を使っていたことがありました
が、確かにごく普通に書いただけの SQL ではなかなか性能が出ないことがあ
りました。

その時は、
1) まずボトルネックとなっている処理 (ある SQL が原因のこともあれば、
DB とは関係ない別のところが原因のこともありました) を探し、
2) SQL が原因の場合は同じ結果が得られるいろいろなパターンのやり方をひ
たすら explain や実時間レベルで比較して
地道にチューニングしていました。具体的には例えば in や or は遅いので
exists に置き換えるとか、カーディナリティが低いフィールドを探索する
select を止めて別テーブルにする、多数の結果を返す SQL で offset/limit
を使って結果を制限する、後はセオリー通りの逆正規化などでしょうか。

先入観や思いこみでチューニングしようとしてもなかなかうまくいかないので
はないかと思います。こういった場合のセオリーとしては、きちんとプロファ
イリングして (もちろんあらかじめプロファイリングに必要な情報が得られる
よう、仕掛けをしておく必要があるかもしれません) ボトルネックとなってい
る処理を探し、そこを集中的にチューニングすることです。

> うちの場合、PL/pgSQLでやれることはなるべくやらせて、それでも重くなる
> コアなコードはCで書いて組み込むこともあります。
> PHPは入出力と画面遷移、そしてセッション管理だけに専念してくれれば
> いいのではないでしょうか。という発想。

PHP のようにフロント側の記述力に限界がある環境などでは PL/pgSQL の利
用には大きなメリットがありそうですね。

僕が作っていたシステムでは前側が Java だったこと、特定の RDBMS に依存
しないようにしたかったことなどから、ロジックは全て Java 側で実装しまし
た。それぞれのやり方にメリット、デメリットがあるわけで、特定の方法論に
こだわらず、解決すべき問題によって柔軟に対応できるのが一番ですね。

何かの参考になれば。

-- 
  ◇   加澤恒央 Tsunehisa KAZAWA
◇  ◇ mailto:kazawa ＠ ca2.so-net.ne.jp
  ◇   http://www.digitune.org/