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

[Tsunehisa Kazawa]

加澤です。

sugita ＠ sra.co.jp wrote:
> ;;; 2) SQL が原因の場合は同じ結果が得られるいろいろなパターンのやり方をひ
> ;;; たすら explain や実時間レベルで比較して
> ;;; 地道にチューニングしていました。
>
>   特定のクエリーが問題の場合にはこれで、それもやり尽くすと、処理フローの見直し
> でしょうか。

そうですね。僕等の場合、ここでどうしようもなくなると別のレイヤーで
解決していました。つまり RDBMS 側ではなくアプリケーションサーバ側
(Java アプリ側) で解決してしまうわけです。

// 具体的にはデータをキャッシュしてしまったり。

DB にデータが集中している場合に比べるとデータ一貫性の確保などに気を
使わなければならない場面が増えてしまいますが、よりアプリケーション
と密着した部分で必要なデータのみを保持出来るようになるためパフォー
マンスは劇的に向上させられます。

もちろん、JavaVM の heap や GC のチューニングなど、また別のところ
でいろいろと苦労する羽目になるわけですけど…(^^;。

> ;;; 				    具体的には例えば in や or は遅いので
>
>   他のパターンもあったと思いますが、少なくとも IN (SELECT 外部参照なし) は
> 7.4devel での改良で、クエリーを書き換えずに済むくらいに速くなっています。

おお。それは素晴らしい。

> ;;; exists に置き換えるとか、
>
>   バージョンは 7.2 ででしたが、EXIST (SELECT 外部参照) が遅くて、書き換えなけ
> ればならないことがありました。DB2 で、同じデータで試すと、よいプランを出して、
> 速度も書き換えずに済む程度に速かったです。

exist で指定されたサブクエリ自体が遅い場合、という感じでしょうか。
どちらにせよ盲目的に in ではなく exist を使っていればいい、という
わけではないわけですね。

// 最近は Oracle をよく使っているのですが、生粋の Oracle 人は in
// を多用し「exist？なにそれ？」状態なのを見て結構ショックだったり。

> ;;; 			     カーディナリティが低いフィールドを探索する
> ;;; select を止めて別テーブルにする、
>
>   やはりこれになりますか。
>
>   単純な検索での例でしかありませんが、int で、カーディナリティ 2 の場合に、10
> 万ずつ別テーブルに分けて、継承で親を作ってまとめても扱えるようにした場合に、子
> テーブルそれぞれの全検索が 25% 速くなりました。また、10 万レコード、int で、カー
> ディナリティが 3 の場合に、クラスタ化すると最初の 2 つのそれぞれの全検索は、
> 12% 前後速くなりましたが、3 つめが 9.5% 遅くなりました。

Oracle ではこういう場合 bitmap index や partition を利用するわけ
ですけれども、PostgreSQL では partition と同じような目的で継承を
利用することが出来る、と考えていいのでしょうか？

＊＊＊

対 Oracle で言うなら、bitmap index や partition よりも表領域にあ
たるレイヤーを PostgreSQL が持っていない点がちょっともどかしいです
ね。OS レベルでの物理データ領域とテーブルレベルでの論理データ領域を
分けて考えられる、というのは何かと便利です (I/O 分散やデータファイ
ルの追加などなど…)。

それでは。

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