半結合最適化について
半結合最適化では、左側(LHS)から返される一意の値を使用して2番目のデータソースにプッシュされるFETCHを書き換えることで、右側(RHS)から取得される行の数を減らします。この最適化には、テーブルのカーディナリティを指定する必要があります。
内部結合では、半結合最適化を使用できます。左右の外部結合では、外側から内側へのみ半結合最適化を使用できます。完全外部結合は、半結合最適化ではサポートされません。
ビューを定義するSQLで、半結合最適化の使用を指定できます。ソース側とターゲット側のテーブルカーディナリティがわかっていて、その2つの比率が好ましい場合、TDVクエリーエンジンは自動的に半結合最適化を使用します。
半結合を試行できるのは、右側を、INまたはOR句をサポートするデータソースに対してフェッチするノードとしてクエリーできる場合のみです。
内部結合と左外部結合の場合、半結合最適化では、常にLHSからの行を使用してRHSを制限します。たとえば、この場合はLHSがソース側で、RHSがターゲットです。右外部結合の場合、状況は逆になります。RHSがソースで、LHSがターゲットです。
別の例として、テーブルEmployeeとDeptおよびそれらの半結合について考えてみます。
従業員名 | EmpId | DeptName |
Harry | 3415 | 財務 |
Sally | 2241 | 営業 |
George | 3401 | 財務 |
Harriet | 2202 | 製造 |
Dept DeptName | Manager |
営業 | Bob |
営業 | Thomas |
製造 | Katie |
製造 | Mark |
従業員テーブルと部門テーブルを半結合すると、次のテーブルになります。
従業員を部門名に結合 | EmpId | DeptName |
Sally | 2241 | 営業 |
Harriet | 2202 | 製造 |
次のような別のクエリーについて考えてみましょう。
SELECT * FROM DS1.R INNER JOIN DS2.T ON R.r = T.t
通常の評価では、Rテーブル式をハッシュしてからTテーブル式を反復処理し、ハッシュテーブルを検索して一致する行を見つけます。この例の結合が、R側からの行数がT側からの行数よりもはるかに少ないものである場合、追加の最適化が可能です。Rからの行はTDVでバッファリングされますが、「t IN (1,6,8,93…)」という形式の追加の述語がRHS用に生成されたSQLに追加されます。IN句のRHSの値は、結合のLHSからのすべての「r」値です。この追加の述語により、TDVが結合を実行するためにT側から取得する行の数が可能な限り少なくなることが保証されます。