Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

10.2. クエリープランナー

user コマンドの各サブコマンドについて、適切なサブプランナー（辞書、XML、手順など）が使用されます。

各プランナーには、3 つの主要なフェーズがあります。

  1. 正規プランの生成
  2. 最適化
  3. コンバーターでコンバーターで処理をプランニングする場合は、データ構造を処理フォームにプランニングします。

リレーショナルデータベースプランナー

論理計画が一連のルールで操作した後に、オーソナイザーによってリレーショナルデータベース処理計画が作成されます。ルールの適用は、クエリー構造とルール自体によって決定されます。デバッグプランのノード構造は処理計画のようになりますが、ノードタイプはより論理的に SQL 操作を表します。

正規計画およびすべてのノード

Planning overview で説明されているように、クエリーエンジンに送信された SQL ステートメントは、正規プランフォームに変換される前に解析、解決、検証、および書き換えられます。正規計画のフォームは、最初の SQL 構造とほぼ同じです。SQL 選択クエリーには、以下の使用可能な句があります(All but SELECT are optional): WITH, SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMITこれらの句は、以下の順序で論理的に実行されます。

  1. WITH（共通のテーブル式を作成）specifically PROJECT NODE が行います（共通のテーブル式を作成）。
  2. FROM（テーブルからすべてのデータを読み取りおよび結合））、from 句項目ごとに SOURCE ノード、または Join ノード（>1 テーブルの場合）が SOURCE ノードによって結合されます。
  3. SELECT ノードによる WHERE（フィルター行）autoMember-gitopsProcessed。
  4. GROUP BY（グループ行を折りたたんだ行に分類）GROUP ノードにより GROUP-2Processed。
  5. HAVING（フィルターグループ化された行）で SELECT ノードを使用。
  6. SELECT（evaluate 式および要求された行のみを返します）は、PROJECT ノードおよび DUP_REMOVE ノード（SELECT DISTINCT 用）で で使用された行のみを返します。
  7. INTOで出所： SOURCE 子を持つ特別な PROJECT を処理します。
  8. ORDER BY（ソート行）で、SORT ノードによって付けられます。
  9. LIMIT（結果を特定の範囲に制限）LIMIT - LIMIT ノードによって満たされます。

たとえば、SELECT max(pm1.g1.e1)FROM pm1.g1 WHERE e2 = 1 などの SQL ステートメントが論理プランを作成します。

images/dv_query_plan.png 

Project(groups=[anon_grp0], props={PROJECT_COLS=[anon_grp0.agg0 AS expr1]})
  Group(groups=[anon_grp0], props={SYMBOL_MAP={anon_grp0.agg0=MAX(pm1.G1.E1)}})
    Select(groups=[pm1.G1], props={SELECT_CRITERIA=pm1.G1.E2 = 1})
      Source(groups=[pm1.G1])
Copy to Clipboard Toggle word wrap

ここでは、Source は FROM 句に対応し、Select は WHERE 句に対応し、Group は最大アグリゲートを作成する暗黙的なグループ化に対応し、Project は SELECT 句に対応します。

注記

グループ化により、グループによって作成される値の展開を処理するインラインビューである anon_grp0 が生成されます。

Expand
表10.1 ノードタイプ
タイプ名説明

ACCESS

ソースアクセスまたはプランの実行。

DUP_REMOVE

重複行を削除します。

JOIN

参加（LEFT OUTER、FULL OUTER、INNER、CROSS、SEMI など）。

PROJECT

タプル値の展開

SELECT

タプルのフィルタリング

SORT

joins などの他の操作を処理するために挿入できる順序付け操作。

ソース

インラインビュー、ソースアクセス、XMLTABLE などを含むタプルの論理ソース。

グループ

グループ化操作。

SET_OP

セット操作(UNION/INTERSECT/EXCEPT)。

NULL

タプルのないソース。

TUPLE_LIMIT

行オフセット / 制限

ノードのプロパティー

各ノードには、通常ノードに表示される適用可能なプロパティーのセットがあります。

Expand
表10.2 アクセスプロパティー
プロパティー名説明

ATOMIC_REQUEST

ソース要求の最終フォーム。

MODEL_ID

ターゲットモデル/スキーマのメタデータオブジェクト。

PROCEDURE_CRITERIA/PROCEDURE_INPUTS/PROCEDURE_DEFAULTS

プランニング手順のリレーショナルデータベースクエリーで使用されます。

IS_MULTI_SOURCE

ノードがマルチソースアクセスを表す場合は true に設定します。

SOURCE_NAME

複数ソース名を追跡するのに使用します。

CONFORMED_SOURCES

準拠した拡張メタデータが使用される場合に、準拠したソースのセットを追跡します。

SUB_PLAN/SUB_PLANS

マルチソースのプランニングで使用されます。

Expand
表10.3 操作プロパティーの設定
プロパティー名説明

SET_OPERATION/USE_ALL

set 操作(UNION/INTERSECT/EXCEPT)およびすべての行または異なる行が使用される場合を定義します。

Expand
表10.4 結合プロパティー
プロパティー名説明

JOIN_CRITERIA

すべての結合述語。

JOIN_TYPE

join のタイプ（INNER、LEFT OUTER など）。

JOIN_STRATEGY

使用するアルゴリズム（入れ子ループ、マージなど）

LEFT_EXPRESSIONS

結合の左側から発信される equi-join 述語の式。

RIGHT_EXPRESSIONS

結合の右側の equi-join 述語の式。

DEPENDENT_VALUE_SOURCE

依存する結合が使用されている場合に設定します。

NON_EQUI_JOIN_CRITERIA

同等でない結合述語。

SORT_LEFT

結合処理用に左側でソートする必要がある場合。

SORT_RIGHT

参加処理に右側のソートが必要な場合は、以下を行います。

IS_OPTIONAL

join が任意の場合。

IS_LEFT_DISTINCT

左側が、equi 結合述語に関して異なる場合。

IS_RIGHT_DISTINCT

右側が、equi 結合述語に関して異なる場合。

IS_SEMI_DEP

依存する結合が半結合を表す場合。

保存

preserve ヒントが結合順序を保持する場合。

Expand
表10.5 プロジェクトのプロパティー
プロパティー名説明

PROJECT_COLS

Projected 式。

INTO_GROUP

このグループが、クエリー式で選択または挿入する場合にターゲットになります。

HAS_WINDOW_FUNCTIONS

ウィンドウ関数を使用している場合は True。

制約

値がグループに展開される場合に満たさなければならない制約。

UPSERT

挿入が upsert の場合。

Expand
表10.6 プロパティーの選択
プロパティー名説明

SELECT_CRITERIA

フィルター。

IS_HAVING

フィルターがグループ化後に適用される場合。

IS_PHANTOM

ノードが削除対象とマークされているが、プランに一時的に残されている場合は True。

IS_TEMPORARY

最終的なプランで使用されていない可能性のある推論された基準。

IS_COPIED

条件がルールのコピー基準ですでに処理されている場合は、

IS_PUSHED

条件をできるだけ早くプッシュする場合は、

IS_DEPENDENT_SET

基準が依存する結合のフィルターである場合。

Expand
表10.7 ソートプロパティー
プロパティー名説明

SORT_ORDER

ソートを定義する順序。

UNRELATED_SORT

順序に展開されていない値が含まれる場合。

IS_DUP_REMOVAL

ソートが展開全体に対して重複削除を実行する必要がある場合。

Expand
表10.8 ソースプロパティー
プロパティー名説明

SYMBOL_MAP

ソース上のコラムから展開された式へのマッピング。グループノードにも存在します。

PARTITION_INFO

ユニオンブランチのパーティション設定。

VIRTUAL_COMMAND

ソースがビューまたはインラインビューを表す場合は、ビューで定義したクエリーです。

MAKE_DEP

ヒント情報。

PROCESSOR_PLAN

（通常は NESTED_COMMAND からの）非リレーショナルデータベースソースのプロセッサープラン。

NESTED_COMMAND

非リレーショナルデータベースコマンド。

TABLE_FUNCTION

ソースを定義するテーブル関数（XMLTABLE、OBJECTTABLE など）。

CORRELATED_REFERENCES

ソースの下にあるノードの相関参照。

MAKE_NOT_DEP

make not dep が設定されている場合。

INLINE_VIEW

ソースノードがインラインビューを表示する場合。

NO_UNNEST

no_unnest ヒントが設定されている場合。

MAKE_IND

make が hint が設定されている場合。

SOURCE_HINT

ソースヒント「 Federated optimizations 」を参照してください。

ACCESS_PATTERNS

アクセスパターンがまだ満たされている必要があります。

ACCESS_PATTERN_USED

一貫性のあるアクセスパターン。

REQUIRED_ACCESS_PATTERN_GROUPS

アクセスパターンを満たすために必要なグループ。結合計画で使用されます。

注記

関連付けられたアクセスノードに多くのソースプロパティーが存在します。

Expand
表10.9 グループプロパティー
プロパティー名説明

GROUP_COLS

グループ化列。

ROLLUP

グループにロールが含まれる場合。

Expand
表10.10 タプルの制限プロパティー
プロパティー名説明

MAX_TUPLE_LIMIT

生成されたタプルの最大数を評価する式。

OFFSET_TUPLE_COUNT

開始タプルのタプルオフセットを評価する式。

IS_IMPLICIT_LIMIT

制限がリライトャーによってサブクエリーの最適化の一環として作成される場合。

IS_NON_STRICT

順序のない制限を厳格に強制することはできません。

Expand
表10.11 一般および費用のプロパティー
プロパティー名説明

OUTPUT_COLS

ノードの出力コラム。通常、ルールは出力要素を割り当てた後に設定されます。

EST_SET_SIZE

依存する結合シナリオにおいて、このノードが独立したノードとして生成する、予想されるセットサイズを表します。

EST_DEP_CARDINALITY

依存する結合シナリオの依存するノードとして、このノードで生成した予測されたカーディナリティー（行をマウントする）を表す値。

EST_DEP_JOIN_COST

依存する参加の推定コスト（この参加ストラテジーは Nested Loop または Merge）を表す値。

EST_JOIN_COST

マージ参加の推定コスト（この参加ストラテジーは Nested Loop または Merge）を表す値。

EST_CARDINALITY

このノードで生成した予測されたカーディナリティー（行のマウント）を表します。

EST_COL_STATS

null 値の数、一意の値数などを含む列の統計。

EST_SELECTIVITY

条件ノードの選択を表します。

ルール

リレーショナルデータベースの最適化は、最初のプランを実行プランに進化させるルール実行に基づいています。すべてのクエリーについてルールスタックに動的にアセンブルされる事前定義済みのルールのセットがあります。  ルールスタックは、ユーザーのクエリーの内容と、アクセスされたビュー/手順に基づいてアセンブルされます。  たとえば、ビュー層がない場合、ビュー層をマージするルール Merge Virtual は必要なく、スタックに追加されません。 これにより、ルールスタックはクエリーの複雑さを反映します。

プランノードのデータ構造は、リーフノード（通常は最終プランのノードへのアクセス）からソースデータが起動するノードのツリーを表します。これは、ツリーを通過してユーザーの結果を生成します。  プラン構造のノードには双方向のリンク、動的プロパティーを持たせることができ、任意の数の子ノードが許可されます。  通常、処理計画には固定プロパティーがあります。

プランルールは、プランツリーを操作して他のルールを実行し、最適化プロセスをアクティブ化します。各ルールは、限定されたタスクセットを実行するように設計されています。一部のルールは複数回実行できます。ルールによっては、正しく実行するのに特定のプリcursors のセットが必要です。

  • アクセスパターンに、すべてのアクセスパターンが満たされていることを確認できます。
  • Securitygitops-gitopsApplies 行および列レベルのセキュリティーを適用します。
  • このルールは、すべてのノードの上方向にスクロールして、各ノードの出力コラムを計算します。  不要な列は、すべてのプロジェクトでドロップされます。これは、展開が最小限に抑えられます。  これは、親ノードのフィードに必要な列の両方を追跡し、特定ノードで「作成された」列を追跡することで行われます。
  • コストの計算： 計画へのコスト情報の追加

  • このルールは各結合ノードを確認し、結合が依存すべきかどうか、またどの方向にするかを決定します。カーディナリティー、個別の値の数、およびプライマリーキー情報は、複数の式で使用され、依存する参加が悪いかどうかを判断します。依存する結合は、依存する側から返される値の数が少ないため、パフォーマンスに異なります。 

    また、独立した値から依存関係にある値の数も考慮する必要があります。セットが依存側の IN 条件の値の最大数よりも大きい場合は、クエリーをクエリーセットに分割し、それらの結果を組み合わせる必要があります。 コネクターの各クエリーの実行にはオーバーヘッドがあり、考慮されます。情報を縮小しないと、指定された基準が一意でない（ただし非常に制限あり）上にある多くの一般的なケースが見なされます。

    結合は、以下の条件に依存できます。

    • tablea.col = tableb.colなど、最低 1 つの結合条件がある。
    • 結合は完全な外部参加ではなく、参加に依存するのは参加の内側の側にあります。

結合は、以下の条件のいずれかが優先順位に一覧表示されているかどうかによって変わります。

  • 依存する参加条件で満たすことができる、満たされていないアクセスパターンがあります。
  • 結合の潜在的な依存関係には、makedep オプションが付いています。
  • (4.3.2)コストが有効な場合には、依存する参加の推定コスト（内部参加の場合の各方向の推定コスト）が計算され、依存する参加が行われないことと比較されます。コストがすべて決定されると（関連するすべてのテーブルカーディナリティ、列のアドビ、および場合によっては nnv の値）最も低いものが選択されます。
  • キーのメタデータ情報が、潜在的な依存側が「small」ではなく、もう一方の側が「小さすぎる」、または(5.0.1)場合、依存するサイドが左側で出入りすることを意味します。

依存する結合は、マルチソース参加を効率的に処理するために使用する主要な最適化です。ソース A およびすべてのソース B を読み取り、A.x = B.x に参加するのではなく、すべての A を読み込んでから、B のクエリー時に条件として渡される A.x のセットを構築します。A が小型の、B が大きい場合、これは B から取得したデータを大幅に減らすことができるため、全体的なクエリーを大幅にスピードアップします。

  • Join Strategyで参加ストラテジーの選択を、参加コストおよび属性に基づいて選択してください。
  • clean criteriagitops-TEMPLATESRemoves phantom 条件。
  • Sourcegitops-gitops を折りたたむと、アクセスノードの下のすべてのノードが取得され、SQL クエリー表現が作成されます。
  • このルールは、結合の基準に存在する等価基準よりも条件をコピーします。  等価性は同等のものを定義するため、参加の一方の側で結果を制限する新しい基準を作成するのに有効な方法です（特に、マルチソース参加の場合）。
  • このルールは、パーティションが分割された結合の結合に対して、パーティション単位で最適化を実行します。詳細は、『 Federated optimizations 』の「 Partitioned unions 」を参照してください。補正する決定は、結合の各側がパーティション化していることを検知することに基づいています（ANSI 以外の結合により、2 つ以上のテーブルが結合すると最適化が適切な参加が検出されない可能性があります）。現在、ルールは、各側から最大 1 つのパーティションが一致する状況のみを検索します。
  • 選択した結合ストラテジーを処理するために必要なソートおよびその他のノードの実装
  • Select nodes（Lerginer ctCombines が選択したノードをマージ）
  • 仮想マシンのビュー層とインラインビュー層のマージ
  • ソースノード下のノードにアクセスするノードへのアクセス先へのアクセスを配置します。アクセスノードは、アクセスノード下のすべてがソースにプッシュされるか、またはプランの呼び出しである時点を表します。それ以降のルールは、アクセス下にプッシュするか、またはツリーを介してアクセスノードをプルして、ソースにより多くの作業を下に移動します。 このルールは、アクセスパターンの配置も行います。詳細は、「Federated optimizations」の「 Access pattern in Federated optimizations」 を参照してください。

  • 参加の計画を立て、このメソッドは、アクセスパターンの依存関係を満たしながら、プランで実行される結合の最適な順序を見つけようとします。このルールには、3 つの主要な手順があります。

    1. アクセスパターンの条件を満たす参加の順序を決定する必要があります。
    2. ソースにプッシュできる結合をヒューリスティックに作成します（結合セットがソースにプッシュされている場合は、そのセット内で最適な順序を作成できなくなります）。ANSI 以外のマルチ結合構文でソースに送信され、データベースによって最適化される可能性が高くなります。 
    3. コスト情報を使用し、処理エンジンで実行される結合の最適な順序を決定します。この 3 番目のステップは、結合ソース 7 以下の完全な検索を実行し、8 以上のソースについてオブジェクリティーに参加することでヒューリスティックに実行されます。
  • プッシュダウンを改善できるように許可されているように、Outer Joinsで結合の計画を立てます。
  • プランニング手順： 段階的なリレーショナルデータベースに表示される手順
  • ソート操作や移動プロジェクトの組み合わせなど、ソート関連の並べ替えを計画する。
  • Data Virtualization 12 用に SubqueriesTEMPLATES-gitopsNew を計画します。Merge criteria で実行されたサブクエリーの最適化を一般化し、展開とフィルタリングの両方でサブクィジションから参加計画を作成できるようにします。
  • プランの Unions Experience-gitopsReorders Unorders union children for more pushdown.
  • Plan Aggregatesgitops-gitopsPerforms aggregate decomposition over a join or union.
  • 制限制限をプッシュ - プランにさらに制限ノードの影響を軽減します。
  • 参加以外の条件をプッシュすると、このルールで結合の正確性が必要なければ、on 句から述語がプッシュされます。
  • Select Violation-gitopsPush をプッシュすると、アクセスノードへの移動、参加、およびビューの層を使用して、できるだけ多くのノードを選択します。  ほとんどの場合、ツリーを下方向に移動すると、プランの前の行がフィルタリングされるためです。現在、プッシュ選択基準により行われる決定は取り消せません。 ただし、基準をソースで評価できない場合には、サブ最適なプランが発生する可能性があります。
  • トランスレーターよりも大きな述語を Large IN TEMPLATES-TEMPLATESPush IN 述語をプッシュすると、直接依存セットとして処理できます。

マージ基準に関連する最も重要な最適化の 1 つは、条件を結合してプッシュする方法です。  クエリーのプランのサブツリーを表す次のプランツリーについて考えてみましょう。B. y = 3 は A inner join b on(A.x = B.x)から選択してください。 

    SELECT (B.y = 3)
           |
          JOIN - Inner Join on (A.x = B.x)
         /     \    
      SRC (A)   SRC (B)
Copy to Clipboard Toggle word wrap
注記

SELECT ノードは基準を表し、SRC は SOURCE を表します。

これは常に内部参加で有効であり、結合の上層にある結合（単一ソース）の条件を結合します。  これにより、ユーザークエリーの発信基準が最終的に結合の下にあるソースクエリーに存在することができます。 この結果は以下のように視覚的に表示できます。 

         
    JOIN - Inner Join on (A.x = B.x)
          /    \
         /   SELECT (B.y = 3)
        |        |
      SRC (A)   SRC (B)
Copy to Clipboard Toggle word wrap

外側の出所に対して指定された基準に同じ最適化が有効です。 以下に例を示します。 

     SELECT (B.y = 3)
           |
          JOIN - Right Outer Join on (A.x = B.x)
         /     \    
      SRC (A)   SRC (B)
Copy to Clipboard Toggle word wrap

become 

          JOIN - Right Outer Join on (A.x = B.x)
          /    \
         /   SELECT (B.y = 3)
        |        |
      SRC (A)   SRC (B)
Copy to Clipboard Toggle word wrap

ただし、外部参加の内側の内側に指定された基準は、特別な考慮が必要です。  上記のシナリオは、左または完全の外部参加が同じではありません。以下に例を示します。 

      SELECT (B.y = 3)
           |
          JOIN - Left Outer Join on (A.x = B.x)
         /     \    
      SRC (A)   SRC (B)
Copy to Clipboard Toggle word wrap

become 可能（5.0.2 の直後に利用可能）。 

    JOIN - Inner Join on (A.x = B.x)
          /    \
         /   SELECT (B.y = 3)
        |        |
      SRC (A)   SRC (B)
Copy to Clipboard Toggle word wrap

条件には、結合の内側の側から生成される可能性のある null 値に依存していないため、結合タイプも内部参加に変更されている場合のみ、結合結合のすぐ下にプッシュできます。一方、CAN not be move の null 値の有無に依存する基準。以下に例を示します。 

    SELECT (B.y is null)
           |
          JOIN - Left Outer Join on (A.x = B.x)
         /     \  
      SRC (A)   SRC (B)
Copy to Clipboard Toggle word wrap

前述のプランツリーの条件は結合の上に留まる必要があり、外側の結合は null 値自体を導入している可能性があります。

  • プランが少なくなると、アクセスノードの取得が試行され、アクセスが試行されます。これは主に、ソースの機能を確認し、操作がソースで達成できるかどうかを判断することで行われます。
  • Nullgitops-gitopsRaises null ノードを発生させます。null ノードを設定すると、null ノードよりも古いプランの一部を考慮する必要があります。
  • オプション参加 - JoinsTEMPLATESRemoves は、オプションとしてマークが付けられるか、またはオプションとして決定されている参加を結合します。
  • 関数ベースのインデックスが存在する場合にのみ、Expressions xmvn-TEMPLATESUsed を置き換えます。
  • ソースで必要な場合に Where Allgitops-TEMPLATESEnsures 条件が使用されることを確認します。

コスト計算

ノード操作のコストは、主に、処理する行数（カンディナリティーとも呼ばれる）の数によって決定されます。オプティマイザーは通常、計画の中で最大数点（またはサブプラン）からカードを計算し、通常、ルールの計算コストを計算し、1 つのルールで計画計画やその他の決定を行う場合にとくに参加します。コストの計算は、主に物理テーブルに設定された統計（カーディナリティー、NNV、NDV など）によって転送され、制約の存在（unique、プライマリーキー、インデックスなど）にも影響を与えます。サブ最適なプランが選択されているような状況が選択された場合は、最初に、少なくとも代表的なテーブルのカーディナリティーが関係する物理テーブルに設定されていることを確認してください。

デバッグプランの読み取り

各リレーショナルデータベースサブプランが最適化されると、プランで最適化されている内容と正規の形式が表示されます。 

OPTIMIZE:
SELECT e1 FROM (SELECT e1 FROM pm1.g1) AS x

----------------------------------------------------------------------------
GENERATE CANONICAL:
SELECT e1 FROM (SELECT e1 FROM pm1.g1) AS x

CANONICAL PLAN:
Project(groups=[x], props={PROJECT_COLS=[e1]})
  Source(groups=[x], props={NESTED_COMMAND=SELECT e1 FROM pm1.g1, SYMBOL_MAP={x.e1=e1}})
    Project(groups=[pm1.g1], props={PROJECT_COLS=[e1]})
      Source(groups=[pm1.g1])
Copy to Clipboard Toggle word wrap

手順呼び出しやサブキューを含むクエリーなど、より複雑なユーザークエリーでは、サブ計画が全体的なプラン内で入れ子になる可能性があります。各プランは、最終的な処理計画を表示して終了します。 

----------------------------------------------------------------------------
OPTIMIZATION COMPLETE:
PROCESSOR PLAN:
AccessNode(0) output=[e1] SELECT g_0.e1 FROM pm1.g1 AS g_0
Copy to Clipboard Toggle word wrap

ルールの影響は、ルールが実行される前後にプランツリーの状態で確認できます。たとえば、以下のデバッグログは、ルールのマージ virtual の適用を示しています。これにより、"x" inline view レイヤーが削除されます。 

EXECUTING AssignOutputElements

AFTER:
Project(groups=[x], props={PROJECT_COLS=[e1], OUTPUT_COLS=[e1]})
  Source(groups=[x], props={NESTED_COMMAND=SELECT e1 FROM pm1.g1, SYMBOL_MAP={x.e1=e1}, OUTPUT_COLS=[e1]})
    Project(groups=[pm1.g1], props={PROJECT_COLS=[e1], OUTPUT_COLS=[e1]})
      Access(groups=[pm1.g1], props={SOURCE_HINT=null, MODEL_ID=Schema name=pm1, nameInSource=null, uuid=3335, OUTPUT_COLS=[e1]})
        Source(groups=[pm1.g1], props={OUTPUT_COLS=[e1]})


============================================================================
EXECUTING MergeVirtual

AFTER:
Project(groups=[pm1.g1], props={PROJECT_COLS=[e1], OUTPUT_COLS=[e1]})
  Access(groups=[pm1.g1], props={SOURCE_HINT=null, MODEL_ID=Schema name=pm1, nameInSource=null, uuid=3335, OUTPUT_COLS=[e1]})
    Source(groups=[pm1.g1])
Copy to Clipboard Toggle word wrap

いくつかの重要な計画の決定が、アノテーションとして実施される際にプランに表示されます。たとえば、以下のコードスニペットは、親 SELECT ノードにサポートされないサブクエリーが含まれるため、アクセスノードが表示されないことを示しています。 

Project(groups=[pm1.g1], props={PROJECT_COLS=[e1], OUTPUT_COLS=null})
  Select(groups=[pm1.g1], props={SELECT_CRITERIA=e1 IN /*+ NO_UNNEST */ (SELECT e1 FROM pm2.g1), OUTPUT_COLS=null})
    Access(groups=[pm1.g1], props={SOURCE_HINT=null, MODEL_ID=Schema name=pm1, nameInSource=null, uuid=3341, OUTPUT_COLS=null})
      Source(groups=[pm1.g1], props={OUTPUT_COLS=null})


============================================================================
EXECUTING RaiseAccess
LOW Relational Planner SubqueryIn is not supported by source pm1 - e1 IN /*+ NO_UNNEST */ (SELECT e1 FROM pm2.g1) was not pushed

AFTER:
Project(groups=[pm1.g1])
  Select(groups=[pm1.g1], props={SELECT_CRITERIA=e1 IN /*+ NO_UNNEST */ (SELECT e1 FROM pm2.g1), OUTPUT_COLS=null})
    Access(groups=[pm1.g1], props={SOURCE_HINT=null, MODEL_ID=Schema name=pm1, nameInSource=null, uuid=3341, OUTPUT_COLS=null})
      Source(groups=[pm1.g1])
Copy to Clipboard Toggle word wrap

手順プランナー

手順プランナーはかなりシンプルです。この手順のステートメントを、処理中に実行されるプログラム内の命令に変換します。これはほとんど 1 対 1 のマッピングで、最適化はほとんど行われません。

XQuery

XQuery は、特定の最適化の対象となります。詳細は「 XQuery optimization 」を参照してください。ドキュメントの展開は、最も一般的な最適化です。これは、デバッグプランにアノテーションとして表示されます。たとえば、ドキュメント列 x 文字列パス '@x' を渡して "xmltable（'/a/b' が含まれるユーザークエリーでは、有効な文字列パス '.'）" を指定すると、デバッグ計画には、コンテキストおよびパス XQuery によって効果的に使用されるドキュメントのツリーが表示されます。 

MEDIUM XQuery Planning Projection conditions met for /a/b - Document projection will be used
child element(Q{}a)
  child element(Q{}b)
    attribute attribute(Q{}x)
      child text()
    child text()
Copy to Clipboard Toggle word wrap
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat