[pgsql-jp: 30011] Re: SET STATISTICS の統計情報の目標値決定指標

[Tatsuo Ishii]

石井です．

>   他には、7.3 迄では、IN 副問い合わせの予測コストも、実際と 1 桁以上合わなくな
> ることが殆どで、効率を考えると、副問い合わせの使用にかなりの制約があるのは、と
> てもアプリケーション側に辛いと思えます。

というか，副問い合わせの結果をWHERE句で利用する場合，WHERE句条件の適合
率の予測が常に50%固定になってしまうのが問題なのですよ（これは，関数の
結果をWHERE句で評価する場合も同じことが言えます）．副問い合わせの結果
をブラックボックスとして扱う以上は，しょうがないんじゃないかな．

ご存じのように，7.4では，この手の副問い合わせは内部で展開されて副問い
合わせじゃなくなるので，このあたりはかなり改善されています．

>   完全な予測をできないのであれば、Oracle のように、使用者に実行計画の制御の手
> 段を与えるべきです。

さあ，それはどうなんでしょうね．ユーザがオプティマイザよりも賢ければ良
いのですが，賢くないユーザは（たとえば）何が何でもインデックスを使おう
としてはまるでしょう．

逆にユーザがオプティマイザよりも賢いとすると，ヒント句など使うまでもな
く，迷えるオプティマイザが正しい問い合わせ計画を導き出すように手助けす
ることができます．

ヒント句で問題なのは，実行計画が固定化されやすいことだと思います．検索
条件が変化したり，データ量が変化した場合でも同じ実行計画を使い続けると
気が付かない間にパフォーマンスが劣化します．更に言えば，PostgreSQLのバー
ジョンが上がってよりよい問い合わせ実行方法が導入されても，SQLを書き換
えないとそれが利用できないかもしれません．

さらに，利用者が実行計画をどのように指示するかも問題です．SQLにコメン
トを追加する程度では，複雑な実行計画を完全に指示することはできないでしょ
う．現実的には，「どのインデックスを使え」位しか指示できないのではない
でしょうか．でもそれだと set enable_* to off とたいして変りません．
その程度で良ければ簡単に実装できると思いますが．
--
Tatsuo Ishii