SQLクエリにおいて、結合操作に関連するHintには、特定の結合アルゴリズムを有効または無効にするHintが含まれます。以下に示します：
| ヒントタイプ | 説明 |
|---|---|
USE_MERGE |
このヒントで指定されたテーブルが結合の右側のテーブルとして使用される場合、ソートマージ結合アルゴリズムを使用します。その逆操作は NO_USE_MERGE です。 |
NO_USE_MERGE |
このヒントで指定されたテーブルが結合の右側のテーブルとして使用される場合、ソートマージ結合アルゴリズムを使用しません。その逆操作は USE_MERGE です。 |
USE_HASH |
このヒントで指定されたテーブルが結合の右側のテーブルとして使用される場合、HASH-JOINアルゴリズムを使用します。その逆操作は NO_USE_HASH です。 |
NO_USE_HASH |
このヒントで指定されたテーブルが結合の右側のテーブルとして使用される場合、HASH-JOINアルゴリズムを使用しません。その逆操作は USE_HASH です。 |
USE_NL |
このヒントで指定されたテーブルが結合の左側のテーブルとして使用される場合、NL-JOINアルゴリズムを使用します。その逆操作は NO_USE_NL です。 |
NO_USE_NL |
このヒントで指定されたテーブルが結合の左側のテーブルとして使用される場合、NL-JOINアルゴリズムを使用しません。その逆操作は USE_NL です。 |
PQ_DISTRIBUTE |
結合操作のデータ配分方式を制御します。 |
PQ_MAP |
結合操作でスレーブノードマッピング戦略を使用するように指定します。 |
USE_NL_MATERIALIZATION |
ネストループ結合の左側のテーブルを強制的にマテリアライズします。その逆操作は NO_USE_NL_MATERIALIZATION です。 |
NO_USE_NL_MATERIALIZATION |
マテリアライズされたネストループ結合の左側のテーブルを防ぎます。その逆操作は USE_NL_MATERIALIZATION です。 |
PX_JOIN_FILTER |
最適化エンジンに対し、HASH JOINでJOIN FILTERを使用するように指示します。その逆操作は NO_PX_JOIN_FILTER です。 |
NO_PX_JOIN_FILTER |
最適化エンジンに対し、HASH JOINでJOIN FILTERを無効にするように指示します。その逆操作は PX_JOIN_FILTER です。 |
PX_PART_JOIN_FILTER |
最適化エンジンに対し、PART FILTERを手動で有効にするように指示します。その逆操作は NO_PX_PART_JOIN_FILTER です。 |
NO_PX_PART_JOIN_FILTER |
最適化エンジンに対し、PART FILTERを手動で無効にするように指示します。その逆操作は NO_PX_PART_JOIN_FILTER です。 |
USE_MERGE ヒント
USE_MERGE ヒントは、このヒントで指定されたテーブルが結合の右側のテーブルとして使用される場合にソート・マージ結合アルゴリズムを使用します。その逆の操作は NO_USE_MERGE です。
構文
/*+ USE_MERGE ( [ @queryblock ] tablespec [ tablespec ]... ) */
使用方法と注意点
USE_NLおよびUSE_MERGEヒントは、LEADINGまたはORDEREDヒントと一緒に使用することを推奨します。引用されるテーブルが結合の右側のテーブルの場合、オプティマイザーはこれらのヒントを使用します。
引用されるテーブルが左側のテーブルの場合、ヒントは無視されます。
USE_MERGEは、テーブルを右側のテーブルとして指定した場合にMERGE JOINアルゴリズムを使用します。OceanBaseデータベースでは、
MERGE JOINアルゴリズムを使用する場合には等価条件のあるjoin-conditionが必要であるため、等価条件のない2つのテーブルを結合する場合、USE_MERGEは無効です。
例
-- USE_MERGE ヒントを使用して、オプティマイザーにソート・マージ結合アルゴリズム（sort-merge join）を使用してクエリを実行するよう指示します
-- employeesテーブルとdepartmentsテーブルの結合操作において、employeesテーブルは右側のテーブルとして、departmentsテーブルは左側のテーブルとして使用されます
SELECT /*+ USE_MERGE(employees departments) */ *
FROM employees, departments
WHERE employees.department_id = departments.department_id;
NO_USE_MERGE ヒント
NO_USE_MERGE ヒントは、指定されたテーブルを左側のテーブルとして使用し、別の行リソースにパラレル接続する際に、USE_MERGE ヒントで使用される結合を除外するようオプティマイザーに指示します。その逆の操作は USE_MERGE です。
構文
/*+ NO_USE_MERGE ( [ @queryblock ] tablespec [ tablespec ]... ) */
例
-- NO_USE_MERGE ヒントを使用して、オプティマイザーにソート・マージ結合アルゴリズムを使用しないようにクエリの実行を指示します。
-- employeesテーブルとdepartmentsテーブルの結合操作では、ソート・マージ結合アルゴリズムの使用が除外されます。
SELECT /*+ NO_USE_MERGE(e d) */ *
FROM employees e, departments d
WHERE e.department_id = d.department_id;
USE_HASH ヒント
USE_HASH ヒントは、指定されたテーブルが結合の右側のテーブルとして使用される場合に、HASH-JOINアルゴリズムを使用するように指示します。その逆操作は NO_USE_HASH です。
構文
/*+ USE_HASH ( [ @queryblock ] tablespec [ tablespec ]... ) */
例
-- USE_HASH ヒントを使用して、オプティマイザーにハッシュ結合アルゴリズム（HASH-JOIN）を使用してクエリを実行するように指示します。
-- ordersテーブルとorder_itemsテーブルの結合操作では、ordersテーブルが右側のテーブルとなり、order_itemsテーブルが左側のテーブルとなります。
SELECT /*+ USE_HASH(l h) */ *
FROM orders h, order_items l
WHERE l.order_id = h.order_id
AND l.order_id > 2400;
NO_USE_HASH ヒント
NO_USE_HASH ヒントは、指定されたテーブルが結合の右側のテーブルとして使用される場合、HASH-JOINアルゴリズムを使用しないように指示します。その逆操作は USE_HASH です。
構文
/*+ NO_USE_HASH ( [ @queryblock ] tablespec [ tablespec ]... ) */
例
-- NO_USE_HASH ヒントを使用して、オプティマイザーにハッシュ結合アルゴリズムを使用してクエリを実行しないように指示します。
-- employeesテーブルとdepartmentsテーブルの結合操作では、HASH-JOINアルゴリズムの使用が除外されます。
SELECT /*+ NO_USE_HASH(e d) */ *
FROM employees e, departments d
WHERE e.department_id = d.department_id;
USE_NL ヒント
USE_NL ヒントは、指定されたテーブルが結合の左側のテーブルとして使用される場合に、ネストループ結合（NL-JOIN）アルゴリズムを使用するように指示します。その逆の操作は NO_USE_NL です。
USE_NLおよびUSE_MERGヒントは、LEADINGまたはORDEREDヒントと一緒に使用することを推奨します。引用されるテーブルが結合の左側のテーブルである場合、オプティマイザーはこれらのヒントを使用します。
引用されるテーブルが右側のテーブルの場合、ヒントは無視されます。
構文
/*+ USE_NL ( [ @queryblock ] tablespec [ tablespec ]... ) */
例
以下のクエリ例に示すように、ヒントによりネストループが強制的に実行され、orders テーブルに対してフルスキャンが行われ、フィルター条件 l.order_id = h.order_id が各行に適用されました。フィルター条件を満たす各行については、インデックス order_id を使用して order_items にアクセスします。
-- USE_NL ヒントを使用して、オプティマイザーにネストループ結合アルゴリズム（NL-JOIN）を使用してクエリを実行するよう指示します。
-- orders と order_items テーブルの結合操作では、orders テーブルが右側のテーブルとなり、order_items テーブルが左側のテーブルとなります。
SELECT /*+ USE_NL(l h) */ h.customer_id, l.unit_price * l.quantity
FROM orders h, order_items l
WHERE l.order_id = h.order_id;
NO_USE_NL ヒント
NO_USE_NL ヒントは、指定されたテーブルが結合の左側のテーブルとして使用される場合、ネストループ結合（NL-JOIN）アルゴリズムを使用しないようにします。その逆の操作は USE_NL です。
構文
/*+ NO_USE_NL ( [ @queryblock ] tablespec [ tablespec ]... ) */
例
-- NO_USE_NL ヒントを使用して、オプティマイザーにネストループ結合アルゴリズムを使用してクエリを実行しないように指示します。
-- employeesテーブルとdepartmentsテーブルの結合操作では、NL-JOINアルゴリズムの使用が除外されます。
SELECT /*+ NO_USE_NL(e d) */ *
FROM employees e, departments d
WHERE e.department_id = d.department_id;
PQ_DISTRIBUTE ヒント
PQ_DISTRIBUTE ヒントは、クエリのパラレル実行時にオプティマイザーに対し、パラレルクエリのプロデューサー（クエリ結果の行データを生成する役割）とコンシューマー（これらの行データを受信して処理する役割）のサーバー間でデータをどのように配分するかを指示します。PQ_DISTRIBUTE ヒントを使用して、接続操作または負荷操作における行データの分散方法を制御できます。
パラレルクエリのシナリオ、特に大量のデータを処理する必要がある場合、PQ_DISTRIBUTE はリソース使用を最適化し、クエリ性能を向上させることができます。
構文
/*+ PQ_DISTRIBUTE
( [ @queryblock ] tablespec
{ distribution | outer_distribution inner_distribution }
) */
接合の割り当てを制御する
指定された2つの割り当て方法を使用して、結合の分散方式を制御できます。
構文の以下の部分に示すように：
outer_distribution左側のテーブルのデータ分散方式を指定します。inner_distribution右側のテーブルのデータ分散方式を指定します。
分散方式には HASH、BROADCAST、PARTITION、NONE が含まれます。有効な組み合わせは、次の表に示す6種類のみです：
| ディストリビューション方式 | 説明 |
|---|---|
| HASH, HASH | 接続キー上のハッシュ関数を使用して、各テーブルの行をクエリサーバーにマッピングします。マッピングが完了すると、各クエリサーバーは一対の結果パーティション間で結合を実行します。 テーブルのサイズが比較可能であり、結合操作がハッシュ結合またはソート・コンパクション結合によって実現される場合、このディストリビューション方式を使用することを推奨します。 |
| BROADCAST, NONE | 右テーブルのすべての行が各クエリサーバーにブロードキャストされます。左テーブルの行はランダムにパーティション化されます。 右テーブルが左テーブルに比べて非常に小さい場合、この分散方法を使用することを推奨します。通常、左テーブルのサイズにクエリサーバー数を乗じた値が右テーブルのサイズを上回る場合も、このディストリビューション方式を使用することを推奨します。 |
| NONE, BROADCAST | 左テーブルのすべての行が各クエリサーバーにブロードキャストされます。右テーブルの行はランダムにパーティション化されます。 左テーブルが右テーブルに比べて非常に小さい場合、この分散方法を使用することを推奨します。通常、左テーブルのサイズにクエリサーバー数を乗じた値が右テーブルのサイズを下回る場合も、このディストリビューション方式を使用することを推奨します。 |
| PARTITION, NONE | 左テーブルの行は右テーブルのパーティションを使用してマッピングされます。左テーブルは結合キー上でパーティション化されていなければなりません。 右テーブルのパーティション数がクエリサーバー数の倍数に等しいか、それに近い場合、このディストリビューション方式を使用することを推奨します。例えば、14個のパーティションと15個のクエリサーバーがある場合です。 注記 左テーブルがパーティション化されていない場合、またはパーティションキー上で均等に結合されていない場合、オプティマイザーはこのヒントを無視します。 |
| NONE, PARTITION | 右テーブルの行は左テーブルのパーティションを使用してマッピングされます。右テーブルは結合キー上でパーティション化されていなければなりません。 右テーブルのパーティション数がクエリサーバー数の倍数に等しいか、それに近い場合、このディストリビューション方式を使用することを推奨します。例えば、14個のパーティションと15個のクエリサーバーがある場合です。 注記 右テーブルがパーティションキー上でパーティション化されていない場合、または均等に結合されていない場合、オプティマイザーはこのヒントを無視します。 |
| NONE, NONE | 各クエリサーバーは、マッチした一対のパーティション間で結合操作を実行します。各テーブルには1つずつ存在します。2つのテーブルは結合キー上で均等に分割されていなければなりません。 |
例
以下のクエリ例に示すように、ハッシュ結合を使用してテーブル r と s の2つのテーブルを結合することを指定します。このクエリには、ハッシュ分散方式を使用するヒントが含まれています。
SELECT /*+ORDERED PQ_DISTRIBUTE(s HASH, HASH) USE_HASH (s) */ column_list
FROM r, s
WHERE r.c = s.c;
右側のテーブル r をブロードキャストする場合、ヒントを含むクエリステートメントは次のとおりです。
SELECT /*+ORDERED PQ_DISTRIBUTE(s BROADCAST, NONE) USE_HASH (s) */ column_list
FROM r, s
WHERE r.c = s.c;
USE_NL_MATERIALIZATION ヒント
USE_NL_MATERIALIZATION ヒントは、オプティマイザーに対し、テーブルが左側のテーブル（サブツリー）として指定された場合に、データをキャッシュするためのマテリアライズド演算子を生成するよう強制的に指示します。その逆の操作は NO_USE_NL_MATERIALIZATION です。
構文
/*+ USE_NL_MATERIALIZATION ( [ @queryblock ] tablespec [ tablespec ]... ) */
例
-- USE_NL_MATERIALIZATION ヒントを使用して、オプティマイザーにネストループ結合内でdepartmentsテーブルをマテリアライズするよう指示します。
SELECT /*+ USE_NL_MATERIALIZATION(departments) */ *
FROM employees, departments
WHERE employees.department_id = departments.department_id;
NO_USE_NL_MATERIALIZATION ヒント
NO_USE_NL_MATERIALIZATION ヒントは、指定されたテーブルを左側のテーブル（サブツリー）として指定した場合に、オプティマイザーがデータをキャッシュするためのマテリアライズド演算子を生成しないよう強制的に指示します。その逆の操作は USE_NL_MATERIALIZATION です。
構文
/*+ NO_USE_NL_MATERIALIZATION ( [ @queryblock ] tablespec [ tablespec ]... ) */
例
-- NO_USE_NL_MATERIALIZATION ヒントを使用して、ネストされたループ結合でdepartmentsテーブルをマテリアライズすることを防ぐ
-- これは、ループ結合のたびにキャッシュされたマテリアライズド結果を使用する代わりに、departmentsテーブルのデータに再アクセスすることを意味します
SELECT /*+ NO_USE_NL_MATERIALIZATION(departments) */ *
FROM employees, departments
WHERE employees.department_id = departments.department_id;
ジョインフィルター（Join Filter）ヒント
ジョインフィルターに関連するヒントは合計4種類あり、最初の2つは通常のジョインフィルターを制御し、後の2つは一部のジョインフィルターを制御します：
PX_JOIN_FILTERヒントNO_PX_JOIN_FILTERヒントPX_PART_JOIN_FILTERヒントNO_PX_PART_JOIN_FILTERヒント
注意すべき点として、これら4つのヒントはパラレル実行環境でのみ有効であり、非パラレル環境では明確な効果はありません。
それぞれの構文とパラメータの説明は以下の通りです：
PX_JOIN_FILTER ヒント
パラレル実行環境において、PX_JOIN_FILTER ヒントはオプティマイザーに対し、HASH JOINでJOIN FILTERを使用するよう指示します。このヒントを使用すると、特定のテーブルをHASH JOINの右側のテーブルとして指定した場合、実行時にJOIN FILTERを用いてフィルタリングを行うことができます。その逆の動作を行うのがNO_PX_JOIN_FILTERです。
構文
/*+ PX_JOIN_FILTER ( [ @qb_name ] filter_table [ left_tables ] [real_filter_table]) */
パラメータの説明
qb_name：ヒントが有効なクエリブロックを指定します。省略可能なパラメータです。filter_table：JOIN FILTERをプッシュダウンする単一のテーブルを記述します。サブクエリの場合、ここにはビューの名前を指定します。left_tables：JOIN FILTERを割り当てる際のHASH-JOINの左側のテーブルを指定します。省略可能なパラメータです。real_filter_table：サブクエリ内で実際にJOIN FILTERをプッシュダウンする単一のテーブルです。
NO_PX_JOIN_FILTER ヒント
NO_PX_JOIN_FILTER ヒントは、オプティマイザーに対し、HASH JOINでのJOIN FILTERを無効にするよう指示します。その逆操作は PX_JOIN_FILTER です。
構文
/*+ NO_PX_JOIN_FILTER( table ) */
PX_PART_JOIN_FILTER ヒント
PX_PART_JOIN_FILTER ヒントは、オプティマイザーにPART FILTERを手動で有効にするよう指示します。その逆の操作は NO_PX_PART_JOIN_FILTER です。
構文
/*+ PX_PART_JOIN_FILTER ( [ @qb_name ] filter_table [ left_tables ] [real_filter_table]) */
NO_PX_PART_JOIN_FILTER ヒント
NO_PX_PART_JOIN_FILTER ヒントは、オプティマイザーにPART FILTERを手動で無効にするよう指示します。その逆の操作は PX_PART_JOIN_FILTER です。
構文
/*+ NO_PX_PART_JOIN_FILTER (table) */
適用シナリオ
結合フィルター（Join Filter）ヒントの4種類のヒント（PX_JOIN_FILTER、NO_PX_JOIN_FILTER、PX_PART_JOIN_FILTER、NO_PX_PART_JOIN_FILTER）は通常、leadingおよびuse_hashヒントと一緒に使用されます。これらのヒントは、leadingおよびuse_hashと組み合わせて使用しない場合、他の結合順序や結合アルゴリズムによって無効になる可能性があります。
汎用的なシナリオ
Join Filterタイプのヒントは、通常LEADINGおよびUSE_HASHと一緒に使用されます。そうでない場合、異なる結合順序や結合アルゴリズムが生成されるため、無効になる可能性があります。
まず、パーティションテーブルを作成します：
CREATE TABLE t1 (
c1 INT,
c2 INT,
c3 INT,
c4 INT
) PARTITION BY HASH(c1) PARTITIONS 10;
Join Filterの強制的な適用
次のSQLを使用して、Join Filterを強制的に適用できます：
EXPLAIN SELECT
/*+ PARALLEL(2) LEADING(a b) USE_HASH(b) PQ_DISTRIBUTE(b BC2HOST NONE)
PX_JOIN_FILTER(b)
PX_PART_JOIN_FILTER(b)
*/ *
FROM t1 a, t1 b WHERE a.c1 = b.c1;
または：
EXPLAIN SELECT
/*+ PARALLEL(2) LEADING(a b) USE_HASH(b) PQ_DISTRIBUTE(b BC2HOST NONE)
PX_JOIN_FILTER(b a)
PX_PART_JOIN_FILTER(b a)
*/ *
FROM t1 a, t1 b WHERE a.c1 = b.c1;
出力される実行計画の例は次のとおりです：
===============================================================
| ID | OPERATOR | NAME | EST. ROWS | COST |
---------------------------------------------------------------
| 0 | PX COORDINATOR | | 1 | 456 |
| 1 | EXCHANGE OUT DISTR | :EX10001| 1 | 456 |
| 2 | SHARED HASH JOIN | | 1 | 455 |
| 3 | JOIN FILTER CREATE | :BF0001 | 1 | 228 |
| 4 | PART JOIN FILTER CREATE | :BF0000 | 1 | 228 |
| 5 | EXCHANGE IN DISTR | | 1 | 228 |
| 6 | EXCHANGE OUT DISTR (BC2HOST)| :EX10000| 1 | 228 |
| 7 | PX BLOCK ITERATOR | | 1 | 228 |
| 8 | TABLE SCAN | a | 1 | 228 |
| 9 | JOIN FILTER USE | :BF0001 | 1 | 228 |
| 10 | PX BLOCK HASH JOIN-FILTER | :BF0000 | 1 | 228 |
| 11 | TABLE SCAN | b | 1 | 228 |
===============================================================
複数テーブルのシナリオ
3つのテーブルを結合する場合、左側のテーブルをaと指定すると、右側のテーブルcに対してJoin Filterを生成できます：
EXPLAIN SELECT
/*+ PARALLEL(2) LEADING(a (b c)) USE_HASH(c (b c)) PQ_DISTRIBUTE((b c) BC2HOST NONE) PQ_DISTRIBUTE(c BC2HOST NONE)
NO_PX_JOIN_FILTER(c)
NO_PX_JOIN_FILTER(b)
NO_PX_PART_JOIN_FILTER(c)
NO_PX_PART_JOIN_FILTER(b)
PX_JOIN_FILTER(c a)
*/ *
FROM t1 a, t1 b, t1 c WHERE a.c1 = c.c1 AND b.c1 = c.c1;
出力される実行計画の例は次のとおりです：
===============================================================
| ID | OPERATOR | NAME | EST. ROWS | COST |
---------------------------------------------------------------
| 0 | PX COORDINATOR | | 1 | 684 |
| 1 | EXCHANGE OUT DISTR | :EX10002| 1 | 683 |
| 2 | SHARED HASH JOIN | | 1 | 683 |
| 3 | JOIN FILTER CREATE | :BF0000 | 1 | 228 |
| 4 | EXCHANGE IN DISTR | | 1 | 228 |
| 5 | EXCHANGE OUT DISTR (BC2HOST) | :EX10000| 1 | 228 |
| 6 | PX BLOCK ITERATOR | | 1 | 228 |
| 7 | TABLE SCAN | a | 1 | 228 |
| 8 | SHARED HASH JOIN | | 1 | 455 |
| 9 | EXCHANGE IN DISTR | | 1 | 228 |
| 10 | EXCHANGE OUT DISTR (BC2HOST) | :EX10001| 1 | 228 |
| 11 | PX BLOCK ITERATOR | | 1 | 228 |
| 12 | TABLE SCAN | b | 1 | 228 |
| 13 | JOIN FILTER USE | :BF0000 | 1 | 228 |
| 14 | PX BLOCK ITERATOR | | 1 | 228 |
| 15 | TABLE SCAN | c | 1 | 228 |
===============================================================
同様に、左側のテーブルをbと指定した3テーブルの結合では、右側のテーブルcに対してJoin Filterを生成できます：
EXPLAIN SELECT
/*+ PARALLEL(2) LEADING(a (b c)) USE_HASH(c (b c)) PQ_DISTRIBUTE((b c) BC2HOST NONE) PQ_DISTRIBUTE(c BC2HOST NONE)
NO_PX_JOIN_FILTER(c)
NO_PX_JOIN_FILTER(b)
NO_PX_PART_JOIN_FILTER(c)
NO_PX_PART_JOIN_FILTER(b)
PX_JOIN_FILTER(c b)
*/ *
FROM t1 a, t1 b, t1 c WHERE a.c1 = c.c1 AND b.c1 = c.c1;
出力される実行計画の例は次のとおりです：
===============================================================
| ID | OPERATOR | NAME | EST. ROWS | COST |
---------------------------------------------------------------
| 0 | PX COORDINATOR | | 1 | 684 |
| 1 | EXCHANGE OUT DISTR | :EX10002| 1 | 683 |
| 2 | SHARED HASH JOIN | | 1 | 683 |
| 3 | EXCHANGE IN DISTR | | 1 | 228 |
| 4 | EXCHANGE OUT DISTR (BC2HOST) | :EX10000| 1 | 228 |
| 5 | PX BLOCK ITERATOR | | 1 | 228 |
| 6 | TABLE SCAN | a | 1 | 228 |
| 7 | SHARED HASH JOIN | | 1 | 455 |
| 8 | JOIN FILTER CREATE | :BF0000 | 1 | 228 |
| 9 | EXCHANGE IN DISTR | | 1 | 228 |
| 10 | EXCHANGE OUT DISTR (BC2HOST) | :EX10001| 1 | 228 |
| 11 | PX BLOCK ITERATOR | | 1 | 228 |
| 12 | TABLE SCAN | b | 1 | 228 |
| 13 | JOIN FILTER USE | :BF0000 | 1 | 228 |
| 14 | PX BLOCK ITERATOR | | 1 | 228 |
| 15 | TABLE SCAN | c | 1 | 228 |
=======================================================================
ヒント：競合処理
PX_JOIN_FILTER と NO_PX_JOIN_FILTER は、左テーブル left_tables が指定されているかどうかに基づいて、4つの有効な形式があります。優先順位に従って、以下の表に従ってマッチングして使用します：
| ヒント | 機能 |
|---|---|
| NO_PX_JOIN_FILTER( a (b c) ) | 左テーブルが(b c)の場合、右テーブルのaに対するjoin filterの使用を禁止します。 |
| PX_JOIN_FILTER( a (b c) ) | 左テーブルが(b c)の場合、右テーブルのaに対するjoin filterの使用を許可します。 |
| NO_PX_JOIN_FILTER( a ) | 任意の結合左テーブルに対して、右テーブルのaに対するjoin filterの使用を禁止します。 |
| PX_JOIN_FILTER( a ) | 任意の結合左テーブルに対して、右テーブルのaに対するjoin filterの使用を許可します。 |
PX_PART_JOIN_FILTER と NO_PX_PART_JOIN_FILTER の競合処理は PX_JOIN_FILTER と同じです。