V5R2 から SQE (SQL Query Engine) という新しくオブジェクト指向で(!)設計されたデータベースエンジンがサポートされるようになりました。
これに伴って、今までのデータベースエンジンは CQE (Classic Query Engine)
という名前が改めて呼ばれるようになっています。
将来のどこかのリリースでは SQE のみになるのでしょうが、現在のところは SQL
によって SQE で実行されたり CQE で実行されたりするようになっています。
どのみち SQL を解析(パース)する、というのはデータベースエンジンで必ず実行される処理です。SQL
解析の段階で、実行プランの中にどちらのエンジンに実行させるかもあわせて決めてディスパッチしてしまえばいいわけで、このディスパッチというものが特別負荷がかかる、とかオーバーヘッドのある過程とは言えません。
この、SQL によって SQE か CQE にディスパッチする機能が Query Dispatcher といわれるものになります。
Query Dispatcher による SQE / CQE へのディスパッチにはきちんとした基準があります。
SQE にディスパッチされるものは以下のようなものです。
Select/Omit のある論理ファイルや部分的に切り出してきたキーなどへの参照があった場合、Query Dispatcher はもし SQE へすでにディスパッチされていた場合は CQE への再ディスパッチを行います。
再ディスパッチするのにオーバーヘッドが 15% 程度ある、というように言われていますが、あまり正確な物言いではありません。これは最適化にかかっている時間が
15% 余計にかかるということです。
では最適化にかかる時間はどんなものかというと、たとえばこちらの例を見てみると 338 ミリ秒です。これが CQE に再ディスパッチされるとこの 15%
程度の時間 (50.7 ミリ秒) がさらに追加される、というだけのことです。SQL
の実際の実行時間の方がはるかに長いわけで、この最適化の時間を惜しんで肝心の実行が遅くなってしまっては本末転倒です。
また、V5R3 から IGNORE_DERIVED_INDEX というオプションで DDS での Select/Omit などを無視させることができます。
もともと、LF に対して SQL を実行するのはあまりいいやり方ではありません。
LF での選択などを前提とせず、SQL できちんと結果が出ないとあとでわけわかんなくなりますので、そういったところの移行もけっこう重要な課題ですね。
|
|