<html>
<head>
<base href="https://docs.jboss.org/author">
<link rel="stylesheet" href="/author/s/en/2172/19/5/_/styles/combined.css?spaceKey=TEIID&forWysiwyg=true" type="text/css">
</head>
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
<h2><a href="https://docs.jboss.org/author/display/TEIID/Query+Plans">Query Plans</a></h2>
<h4>Page <b>edited</b> by <a href="https://docs.jboss.org/author/display/~shawkins">Steven Hawkins</a>
</h4>
<br/>
<h4>Changes (12)</h4>
<div id="page-diffs">
<table class="diff" cellpadding="0" cellspacing="0">
<tr><td class="diff-snipped" >...<br></td></tr>
<tr><td class="diff-unchanged" >Plan rule manipulate the plan tree, fire other rules, and drive the optimization process. The structure of the query determines the initial set of rules. Each rule is designed to perform a narrow set of tasks. Some rules can be run multiple times. Some rules require a specific set of precursors to run properly. <br> <br></td></tr>
<tr><td class="diff-changed-lines" >* Access Pattern Validation <span class="diff-added-words"style="background-color: #dfd;">- ensures that all access patterns have been satisfied</span> <br></td></tr>
<tr><td class="diff-changed-lines" >* Apply Security <span class="diff-added-words"style="background-color: #dfd;">- applies row and column level security</span> <br></td></tr>
<tr><td class="diff-changed-lines" >* Assign Output Symbol <span class="diff-added-words"style="background-color: #dfd;">- determines the output of every node and minimizes projection</span> <br></td></tr>
<tr><td class="diff-changed-lines" >* Calculate Cost <span class="diff-added-words"style="background-color: #dfd;">- adds costing information to the plan</span> <br></td></tr>
<tr><td class="diff-changed-lines" >* Choose Dependent <span class="diff-added-words"style="background-color: #dfd;">- choose dependent joins based upon the cost/hints</span> <br></td></tr>
<tr><td class="diff-changed-lines" >* Choose Join Strategy <span class="diff-added-words"style="background-color: #dfd;">- choose the join strategy base upon the cost</span> <br></td></tr>
<tr><td class="diff-changed-lines" >* Clean Criteria <span class="diff-added-words"style="background-color: #dfd;">- removes phantom criteria and combines other select nodes</span> <br></td></tr>
<tr><td class="diff-changed-lines" >* Collapse Source <span class="diff-added-words"style="background-color: #dfd;">- takes all of the nodes below an access node and creates a SQL query representation</span> <br></td></tr>
<tr><td class="diff-changed-lines" >* Copy Criteria <span class="diff-added-words"style="background-color: #dfd;">- copies criteria based upon join predicates</span> <br></td></tr>
<tr><td class="diff-changed-lines" >* Decompose Join <span class="diff-added-words"style="background-color: #dfd;">-</span> <br></td></tr>
<tr><td class="diff-unchanged" >* Implement Join Strategy <br>* Merge Criteria <br></td></tr>
<tr><td class="diff-snipped" >...<br></td></tr>
<tr><td class="diff-unchanged" >* Remove Optional Joins <br>* Substitute Expressions <br></td></tr>
<tr><td class="diff-changed-lines" >* Validate Where All <span class="diff-added-words"style="background-color: #dfd;">- ensures criteria is used when required by the source</span> <br></td></tr>
<tr><td class="diff-unchanged" > <br>h2. Reading a Debug Plan <br></td></tr>
<tr><td class="diff-snipped" >...<br></td></tr>
<tr><td class="diff-unchanged" > <br>h2. XQuery <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;"> <br>XQuery is eligible for specific [optimizations|XQuery Optimization]. Document projection is the most common optimization. It will be shown in the debug plan as an annotation. For example with the user query containing "xmltable('/a/b' passing doc columns x string path '@x', val string path '/.')", the debug plan would show a tree of the document that will effectively be used by the context and path XQuerys: <br> <br>{code} <br>MEDIUM XQuery Planning Projection conditions met for /a/b - Document projection will be used <br>childelement(Q{}a) <br> childelement(Q{}b) <br> attributeattribute(Q{}x) <br> childtext() <br> childtext() <br>{code} <br></td></tr>
</table>
</div> <h4>Full Content</h4>
<div class="notificationGreySide">
<p>When integrating information using a federated query planner it is useful to view the query plans to better understand how information is being accessed and processed, and to troubleshoot problems.</p>
<p>A query plan is a set of instructions created by a query engine for executing a command submitted by a user or application. The purpose of the query plan is to execute the user's query in as efficient a way as possible.</p>
<h1><a name="QueryPlans-GettingaQueryPlan"></a>Getting a Query Plan</h1>
<p>You can get a query plan any time you execute a command. The SQL options available are as follows:</p>
<p><b>SET SHOWPLAN [ON|DEBUG]</b>- Returns the processing plan or the plan and the full planner debug log. See also the <a href="/author/display/TEIID/SET+Statement" title="SET Statement">SET Statement</a>.</p>
<p>With the above options, the query plan is available from the Statement object by casting to the <tt>org.teiid.jdbc.TeiidStatement</tt> interface or by using the "SHOW PLAN" <a href="/author/display/TEIID/SHOW+Statement" title="SHOW Statement">statement</a>.</p>
<div class="code panel" style="border-width: 1px;"><div class="codeHeader panelHeader" style="border-bottom-width: 1px;"><b>Retrieving a Query Plan</b></div><div class="codeContent panelContent">
<pre class="theme: Confluence; brush: sql; gutter: false" style="font-size:12px; font-family: ConfluenceInstalledFont,monospace;">
statement.execute("set showplan on");
ResultSet rs = statement.executeQuery("select ...");
TeiidStatement tstatement = statement.unwrap(TeiidStatement.class);
PlanNode queryPlan = tstatement.getPlanDescription();
System.out.println(queryPlan);
</pre>
</div></div>
<p>The query plan is made available automatically in several of Teiid's tools.</p>
<h1><a name="QueryPlans-AnalyzingaQueryPlan"></a>Analyzing a Query Plan</h1>
<p>Once a query plan has been obtained you will most commonly be looking for:</p>
<ul>
<li>Source pushdown -- what parts of the query that got pushed to each source
<ul>
<li>Ensure that any predicates especially against indexes are pushed</li>
</ul>
</li>
</ul>
<ul>
<li>Joins - as federated joins can be quite expensive
<ul>
<li>Join ordering - typically influenced by costing</li>
<li>Join criteria type mismatches.</li>
<li>Join algorithm used - merge, enhanced merge, nested loop, etc.</li>
</ul>
</li>
</ul>
<ul>
<li>Presence of federated optimizations, such as dependent joins.</li>
</ul>
<ul>
<li>Ensure hints have the desired affects - see <a href="/author/display/TEIID/Hints+and+Options" title="Hints and Options">Hints and Options</a>, hints in the <a href="/author/display/TEIID/FROM+Clause" title="FROM Clause">FROM Clause</a>, <a href="/author/display/TEIID/Subquery+Optimization" title="Subquery Optimization">Subquery Optimization</a>, and source hints below.</li>
</ul>
<p>All of the above information can be determined from the processing plan. You will typically be interested in analyzing the textual form of the final processing plan. To understand why particular decisions are made for debugging or support you will want to obtain the full debug log which will contain the intermediate planning steps as well as annotations as to why specific pushdown decisions are made. </p>
<p>A query plan consists of a set of nodes organized in a tree structure. If you are executing a procedure or generating an XML document from an XML Document Model, the overall query plan will contain additional information related the surrounding procedural execution.</p>
<p>In a procedural context the ordering of child nodes implies the order of execution. In most other situation, child nodes may be executed in any order even in parallel. Only in specific optimizations, such as dependent join, will the children of a join execute serially.</p>
<h1><a name="QueryPlans-RelationalExecutionPlans"></a>Relational Execution Plans</h1>
<p>Relational plans represent the processing plan that is composed of nodes representing building blocks of logical relational operations. Relational processing plans differ from logical debug relational plans in that they will contain additional operations and execution specifics that were chosen by the optimizer.</p>
<p>The nodes for a relational query plan are:</p>
<ul>
<li>Access - Access a source. A source query is sent to the connection factory associated with the source. [For a dependent join, this node is called Dependent Access.]</li>
</ul>
<ul>
<li>Dependent Procedure Access - Access a stored procedure on a source using multiple sets of input values.</li>
</ul>
<ul>
<li>Batched Update - Processes a set of updates as a batch.</li>
</ul>
<ul>
<li>Project - Defines the columns returned from the node. This does not alter the number of records returned.</li>
</ul>
<ul>
<li>Project Into - Like a normal project, but outputs rows into a target table.</li>
</ul>
<ul>
<li>Insert Plan Execution - Similar to a project into, but executes a plan rather than a source query. Typically created when executing an insert into view with a query expression.</li>
</ul>
<ul>
<li>Window Function Project - Like a normal project, but includes window functions.</li>
</ul>
<ul>
<li>Select - Select is a criteria evaluation filter node (WHERE / HAVING).</li>
</ul>
<ul>
<li>Join - Defines the join type, join criteria, and join strategy (merge or nested loop).</li>
</ul>
<ul>
<li>Union All - There are no properties for this node, it just passes rows through from it's children. Depending upon other factors, such as if there is a transaction or the source query concurrency allowed, not all of the union children will execute in parallel.</li>
</ul>
<ul>
<li>Sort - Defines the columns to sort on, the sort direction for each column, and whether to remove duplicates or not.</li>
</ul>
<ul>
<li>Dup Remove - Removes duplicate rows. The processing uses a tree structure to detect duplicates so that results will effectively stream at the cost of IO operations.</li>
</ul>
<ul>
<li>Grouping - Groups sets of rows into groups and evaluates aggregate functions.</li>
</ul>
<ul>
<li>Null - A node that produces no rows. Usually replaces a Select node where the criteria is always false (and whatever tree is underneath). There are no properties for this node.</li>
</ul>
<ul>
<li>Plan Execution - Executes another sub plan. Typically the sub plan will be a non-relational plan.</li>
</ul>
<ul>
<li>Dependent Procedure Execution - Executes a sub plan using multiple sets of input values.</li>
</ul>
<ul>
<li>Limit - Returns a specified number of rows, then stops processing. Also processes an offset if present.</li>
</ul>
<ul>
<li>XML Table - Evaluates XMLTABLE. The debug plan will contain more information about the XQuery/XPath with regards to their optimization - see the XQuery section below or <a href="/author/display/TEIID/XQuery+Optimization" title="XQuery Optimization">XQuery Optimization</a>.</li>
</ul>
<ul>
<li>Text Table - Evaluates TEXTTABLE</li>
</ul>
<ul>
<li>Array Table - Evaluates ARRAYTABLE</li>
</ul>
<ul>
<li>Object Table - Evaluates OBJECTTABLE</li>
</ul>
<h2><a name="QueryPlans-NodeStatistics"></a>Node Statistics</h2>
<p>Every node has a set of statistics that are output. These can be used to determine the amount of data flowing through the node.</p>
<div class='table-wrap'>
<table class='confluenceTable'><tbody>
<tr>
<th class='confluenceTh'> Statistic </th>
<th class='confluenceTh'> Description </th>
<th class='confluenceTh'> Units </th>
</tr>
<tr>
<td class='confluenceTd'> Node Output Rows </td>
<td class='confluenceTd'> Number of records output from the node </td>
<td class='confluenceTd'> count </td>
</tr>
<tr>
<td class='confluenceTd'> Node Process Time </td>
<td class='confluenceTd'> Time processing in this node only </td>
<td class='confluenceTd'> millisec </td>
</tr>
<tr>
<td class='confluenceTd'> Node Cumulative Process Time </td>
<td class='confluenceTd'> Elapsed time from beginning of processing to end </td>
<td class='confluenceTd'> millisec </td>
</tr>
<tr>
<td class='confluenceTd'> Node Cumulative Next Batch Process Time </td>
<td class='confluenceTd'> Time processing in this node + child nodes </td>
<td class='confluenceTd'> millisec </td>
</tr>
<tr>
<td class='confluenceTd'> Node Next Batch Calls </td>
<td class='confluenceTd'> Number of times a node was called for processing </td>
<td class='confluenceTd'> count </td>
</tr>
<tr>
<td class='confluenceTd'> Node Blocks </td>
<td class='confluenceTd'> Number of times a blocked exception was thrown by this node or a child </td>
<td class='confluenceTd'> count </td>
</tr>
</tbody></table>
</div>
<p>In addition to node statistics, some nodes display cost estimates computed at the node.</p>
<div class='table-wrap'>
<table class='confluenceTable'><tbody>
<tr>
<th class='confluenceTh'> Cost Estimates </th>
<th class='confluenceTh'> Description </th>
<th class='confluenceTh'> Units </th>
</tr>
<tr>
<td class='confluenceTd'> Estimated Node Cardinality </td>
<td class='confluenceTd'> Estimated number of records that will be output from the node; -1 if unknown </td>
<td class='confluenceTd'> count </td>
</tr>
</tbody></table>
</div>
<p>The root node will display additional information.</p>
<div class='table-wrap'>
<table class='confluenceTable'><tbody>
<tr>
<th class='confluenceTh'> Top level Statistics </th>
<th class='confluenceTh'> Description </th>
<th class='confluenceTh'> Units </th>
</tr>
<tr>
<td class='confluenceTd'> Data Bytes Sent </td>
<td class='confluenceTd'> The size of the serialized data result (row and lob values) sent to the client </td>
<td class='confluenceTd'> bytes </td>
</tr>
</tbody></table>
</div>
<h2><a name="QueryPlans-ReadingaProcessorPlan"></a>Reading a Processor Plan</h2>
<h1><a name="QueryPlans-OtherPlans"></a>Other Plans</h1>
<p>XML document model queries and proecedure execution (including instead of triggers) use intermediate and final plan forms that include relational plans. Generally the structure of the xml/procedure plans will closely match their logical forms. It's the nested relational plans that will be of interest when analyzing performance issues.</p>
<h1><a name="QueryPlans-SourceHints"></a>Source Hints</h1>
<p>Teiid user and transformation queries can contain a meta source hint that can provide additional information to source queries. The source hint has the form:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="theme: Confluence; brush: sql; gutter: false" style="font-size:12px; font-family: ConfluenceInstalledFont,monospace;">/*+ sh[[ KEEP ALIASES]:'arg'] source-name[ KEEP ALIASES]:'arg1' ... */</pre>
</div></div>
<ul class="alternate" type="square">
<li>The source hint is expected to appear after the query (SELECT, INSERT, UPDATE, DELETE) keyword.</li>
<li>Source hints may appear in any subquery or in views. All hints applicable to a given source query will be collected and pushed down together as a list. The order of the hints is not guaranteed.</li>
<li>The sh arg is optional and is passed to all source queries via the <tt>ExecutionContext.getGeneralHints</tt> method. The additional args should have a source-name that matches the source name assigned to the translator in the VDB. If the source-name matches, the hint values will be supplied via the <tt>ExecutionContext.getSourceHints</tt> method. See the <a href="/author/display/TEIID/Developer%27s+Guide" title="Developer's Guide">Developer's Guide</a> for more on using an ExecutionContext.</li>
<li>Each of the arg values has the form of a string literal - it must be surrounded in single quotes and a single quote can be escaped with another single quote. Only the Oracle translator does anything with source hints by default. The Oracle translator will use both the source hint and the general hint (in that order) if available to form an Oracle hint enclosed in /*+ ... */.</li>
<li>If the KEEP ALIASES option is used either for the general hint or on the applicable source specific hint, then the table/view aliases from the user query and any nested views will be preserved in the push-down query. This is useful in situations where the source hint may need to reference aliases and the user does not wish to rely on the generated aliases (which can be seen in the query plan in the relevant source queries - see above). However in some situations this may result in an invalid source query if the preserved alias names are not valid for the source or result in a name collision. If the usage of KEEP ALIASES results in an error, the query could be modified by preventing view removal with the NO_UNNEST hint, the aliases modified, or the KEEP ALIASES option could be removed and the query plan used to determine the generated alias names.</li>
</ul>
<div class="code panel" style="border-width: 1px;"><div class="codeHeader panelHeader" style="border-bottom-width: 1px;"><b>Sample Source Hints</b></div><div class="codeContent panelContent">
<pre class="theme: Confluence; brush: sql; gutter: false" style="font-size:12px; font-family: ConfluenceInstalledFont,monospace;">SELECT /*+ sh:'general hint' */ ...
SELECT /*+ sh KEEP ALIASES:'general hint' my-oracle:'oracle hint' */ ...
</pre>
</div></div>
<h1><a name="QueryPlans-DebugPlans"></a>Debug Plans</h1>
<p>A relational processing plan is created by the optimizer after the logical plan is manipulated by a series of rules. The application of rules is determined both by the query structure and by the rules themselves. The node structure of the debug plan resembles that of the processing plan, but the node types more logically represent SQL operations.</p>
<h2><a name="QueryPlans-AllNodes"></a>All Nodes</h2>
<ul>
<li>ACCESS - a source access or plan execution.</li>
<li>DUP_REMOVE - removes duplicate rows</li>
<li>JOIN - a join (LEFT OUTER, FULL OUTER, INNER, CROSS, SEMI, etc.)</li>
<li>PROJECT - a projection of tuple values</li>
<li>SELECT - a filtering of tuples</li>
<li>SORT - an ordering operation, which may be inserted to process other operations such as joins</li>
<li>SOURCE - any logical source of tuples including an inline view, a source access, XMLTABLE, etc.</li>
<li>GROUP - a grouping operation</li>
<li>SET_OP - a set operation (UNION/INTERSECT/EXCEPT)</li>
<li>NULL - a source of no tuples</li>
<li>TUPLE_LIMIT - row offset / limit</li>
</ul>
<p>User SQL statements after rewrite are converted into a cannonical plan form. The connonical plan form most closely resembles the initial SQL structure. For example, a SQL statement such as SELECT max(pm1.g1.e1) FROM pm1.g1 WHERE e2 = 1 creates a logical plan:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="theme: Confluence; brush: java; gutter: false" style="font-size:12px; font-family: ConfluenceInstalledFont,monospace;">
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=e2 = 1})
Source(groups=[pm1.g1])
</pre>
</div></div>
<p>Here the Source corresponds to the FROM clause, the Select correspondes to the WHERE clause, the Group corresponds to the implied grouping to create the max aggregate, and the Project corresponds to the SELECT clause.</p>
<p>Note that the affect of grouping generates what is effectively an inline view, anon_grp0, to handle the projection of values created by the gropuing.</p>
<h2><a name="QueryPlans-NodeProperties"></a>Node Properties</h2>
<p>Each node has a set of applicable properties that are typically shown on the node.</p>
<ul>
<li>Access Properties
<ul>
<li>ATOMIC_REQUEST - The final form of a source request</li>
<li>MODEL_ID - The metadata object for the target model/schema</li>
<li>PROCEDURE_CRITERIA/PROCEDURE_INPUTS/PROCEDURE_DEFAULTS - Used in planning procedureal relational queries</li>
<li>IS_MULTI_SOURCE - set to true when the node represents a multi-source access</li>
<li>SOURCE_NAME - used to track the multi-source source name</li>
<li>CONFORMED_SOURCES - tracks the set of conformed sources when the conformed extension metadata is used</li>
<li>SUB_PLAN/SUB_PLANS - used in multi-source planning</li>
</ul>
</li>
<li>SET_OPERATION/USE_ALL - defines the set operation (UNION/INTERSECT/EXCEPT) and if all rows or distinct rows are used.</li>
<li>Join Properties
<ul>
<li>JOIN_CRITERIA - all join predicates</li>
<li>JOIN_TYPE - type of join (INNER, LEFT OUTER, etc.)</li>
<li>JOIN_STRATEGY - the algorithm to use (nested loop, merge, etc.)</li>
<li>LEFT_EXPRESSIONS - the expressions in equi-join predicates that originate from the left side of the join</li>
<li>RIGHT_EXPRESSIONS - the expressions in equi-join predicates that originate from the right side of the join</li>
<li>DEPENDENT_VALUE_SOURCE - set if a dependent join is used</li>
<li>NON_EQUI_JOIN_CRITERIA - non-equi join predicates</li>
<li>SORT_LEFT - if the left side needs sorted for join processing</li>
<li>SORT_RIGHT - if the right side needs sorted for join processing</li>
<li>IS_OPTIONAL - if the join is optional</li>
<li>IS_LEFT_DISTINCT - if the left side is distinct with respect to the equi join predicates</li>
<li>IS_RIGHT_DISTINCT - if the right side is distinct with respect to the equi join predicates</li>
<li>IS_SEMI_DEP - if the dependent join represents a semi-join</li>
<li>PRESERVE - if the preserve hint is preserving the join order</li>
</ul>
</li>
<li>Project Properties
<ul>
<li>PROJECT_COLS - the expressions projected</li>
<li>INTO_GROUP - the group targeted if this is a select into or insert with a query expression</li>
<li>HAS_WINDOW_FUNCTIONS - true if window functions are used</li>
<li>CONSTRAINT - the constraint that must be met if the values are being projected into a group</li>
</ul>
</li>
<li>Select Properties
<ul>
<li>SELECT_CRITERIA - the filter</li>
<li>IS_HAVING - if the filter is applied after grouping</li>
<li>IS_PHANTOM - true if the node is marked for removal, but temporarily left in the plan.</li>
<li>IS_TEMPORARY - inferred criteria that may not be used in the final plan</li>
<li>IS_COPIED - if the criteria has already been processed by rule copy criteria</li>
<li>IS_PUSHED - if the criteria is pushed as far as possible</li>
<li>IS_DEPENDENT_SET - if the criteria is the filter of a dependent join</li>
</ul>
</li>
<li>Sort Properties
<ul>
<li>SORT_ORDER - the order by that defines the sort</li>
<li>UNRELATED_SORT - if the ordering includes a value that is not being projected</li>
<li>IS_DUP_REMOVAL - if the sort should also perform duplicate removal over the entire projection</li>
</ul>
</li>
<li>Source Properties - many source properties also become present on associated access nodes
<ul>
<li>SYMBOL_MAP - the mapping from the columns above the source to the projected expressions. Also present on Group nodes</li>
<li>PARTITION_INFO - the partitioning of the union branches</li>
<li>VIRTUAL_COMMAND - if the source represents an view or inline view, the query that defined the view</li>
<li>MAKE_DEP - hint information</li>
<li>PROCESSOR_PLAN - the processor plan of a non-relational source (typically from the NESTED_COMMAND)</li>
<li>NESTED_COMMAND - the non-relational command</li>
<li>TABLE_FUNCTION - the table function (XMLTABLE, OBJECTTABLE, etc.) defining the source</li>
<li>CORRELATED_REFERENCES - the correlated references for the nodes below the source</li>
<li>MAKE_NOT_DEP - if make not dep is set</li>
<li>INLINE_VIEW - If the source node represents an inline view</li>
<li>NO_UNNEST - if the no_unnest hint is set</li>
<li>MAKE_IND - if the make ind hint is set</li>
<li>SOURCE_HINT - the source hint. See Source Hints above.</li>
<li>ACCESS_PATTERNS - access patterns yet to be satisfied</li>
<li>ACCESS_PATTERN_USED - satisfied access patterns</li>
<li>REQUIRED_ACCESS_PATTERN_GROUPS - groups needed to satisfy the access patterns. Used in join planning.</li>
</ul>
</li>
<li>Group Properties
<ul>
<li>GROUP_COLS - the grouping columns</li>
<li>ROLLUP - if the grouping includes a rollup</li>
</ul>
</li>
<li>Tuple Limit Properties
<ul>
<li>MAX_TUPLE_LIMIT - expression that evaluates to the max number of tuples generated</li>
<li>OFFSET_TUPLE_COUNT - Expression that evaluates to the tuple offset of the starting tuple</li>
<li>IS_IMPLICIT_LIMIT - if the limit is created by the rewriter as part of a subquery optimization</li>
<li>IS_NON_STRICT - if the unordered limit should not be enforced strictly</li>
</ul>
</li>
<li>General and Costing Properties
<ul>
<li>OUTPUT_COLS - the output columns for the node. Is typically set after rule assign output elements.</li>
<li>EST_SET_SIZE - represents the estimated set size this node would produce for a sibling node as the independent node in a dependent join scenario</li>
<li>EST_DEP_CARDINALITY - value that represents the estimated cardinality (amount of rows) produced by this node as the dependent node in a dependent join scenario</li>
<li>EST_DEP_JOIN_COST - value that represents the estimated cost of a dependent join (the join strategy for this could be Nested Loop or Merge)</li>
<li>EST_JOIN_COST - value that represents the estimated cost of a merge join (the join strategy for this could be Nested Loop or Merge)</li>
<li>EST_CARDINALITY - represents the estimated cardinality (amount of rows) produced by this node</li>
<li>EST_COL_STATS - column statistics including number of null values, distinct value count, etc.</li>
<li>EST_SELECTIVITY - represents the selectivity of a criteria node</li>
</ul>
</li>
</ul>
<h2><a name="QueryPlans-Rules"></a>Rules</h2>
<p>Plan rule manipulate the plan tree, fire other rules, and drive the optimization process. The structure of the query determines the initial set of rules. Each rule is designed to perform a narrow set of tasks. Some rules can be run multiple times. Some rules require a specific set of precursors to run properly.</p>
<ul>
<li>Access Pattern Validation - ensures that all access patterns have been satisfied</li>
<li>Apply Security - applies row and column level security</li>
<li>Assign Output Symbol - determines the output of every node and minimizes projection</li>
<li>Calculate Cost - adds costing information to the plan</li>
<li>Choose Dependent - choose dependent joins based upon the cost/hints</li>
<li>Choose Join Strategy - choose the join strategy base upon the cost</li>
<li>Clean Criteria - removes phantom criteria and combines other select nodes</li>
<li>Collapse Source - takes all of the nodes below an access node and creates a SQL query representation</li>
<li>Copy Criteria - copies criteria based upon join predicates</li>
<li>Decompose Join -</li>
<li>Implement Join Strategy</li>
<li>Merge Criteria</li>
<li>Merge Virtual</li>
<li>Place Access</li>
<li>Plan Joins</li>
<li>Plan Procedures</li>
<li>Plan Sorts</li>
<li>Plan Unions</li>
<li>Plan Aggregates</li>
<li>Push Limit</li>
<li>Push Non-Join Criteria</li>
<li>Push Select Criteria</li>
<li>Raise Access</li>
<li>Raise Null</li>
<li>Remove Optional Joins</li>
<li>Substitute Expressions</li>
<li>Validate Where All - ensures criteria is used when required by the source</li>
</ul>
<h2><a name="QueryPlans-ReadingaDebugPlan"></a>Reading a Debug Plan</h2>
<p>As each relational sub plan is optimized, the plan will show what is being optimized and it's canonical form:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="theme: Confluence; brush: java; gutter: false" style="font-size:12px; font-family: ConfluenceInstalledFont,monospace;">
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])
</pre>
</div></div>
<p>With more complicated user queries, such as a procedure invocation or one containing subqueries, the sub plans may be nested within the overall plan. Each plan ends by showing the final processing plan:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="theme: Confluence; brush: java; gutter: false" style="font-size:12px; font-family: ConfluenceInstalledFont,monospace;">
----------------------------------------------------------------------------
OPTIMIZATION COMPLETE:
PROCESSOR PLAN:
AccessNode(0) output=[e1] SELECT g_0.e1 FROM pm1.g1 AS g_0
</pre>
</div></div>
<p>The affect of rules can be seen by the state of the plan tree before and after the rule fires. For example, the debug log below shows the application of rule merge virtual, which will remove the "x" inline view layer:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="theme: Confluence; brush: java; gutter: false" style="font-size:12px; font-family: ConfluenceInstalledFont,monospace;">
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])
</pre>
</div></div>
<p>Some important planning decisions are shown in the plan as they occur as an annotation. For example the snippet below shows that the access node could not be raised as the parent select node contained an unsupported subquery.</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="theme: Confluence; brush: java; gutter: false" style="font-size:12px; font-family: ConfluenceInstalledFont,monospace;">
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])
</pre>
</div></div>
<h2><a name="QueryPlans-XQuery"></a>XQuery</h2>
<p>XQuery is eligible for specific <a href="/author/display/TEIID/XQuery+Optimization" title="XQuery Optimization">optimizations</a>. Document projection is the most common optimization. It will be shown in the debug plan as an annotation. For example with the user query containing "xmltable('/a/b' passing doc columns x string path '@x', val string path '/.')", the debug plan would show a tree of the document that will effectively be used by the context and path XQuerys:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="theme: Confluence; brush: java; gutter: false" style="font-size:12px; font-family: ConfluenceInstalledFont,monospace;">
MEDIUM XQuery Planning Projection conditions met for /a/b - Document projection will be used
childelement(Q{}a)
childelement(Q{}b)
attributeattribute(Q{}x)
childtext()
childtext()
</pre>
</div></div>
</div>
<div id="commentsSection" class="wiki-content pageSection">
<div style="float: right;" class="grey">
<a href="https://docs.jboss.org/author/users/removespacenotification.action?spaceKey=TEIID">Stop watching space</a>
<span style="padding: 0px 5px;">|</span>
<a href="https://docs.jboss.org/author/users/editmyemailsettings.action">Change email notification preferences</a>
</div>
<a href="https://docs.jboss.org/author/display/TEIID/Query+Plans">View Online</a>
|
<a href="https://docs.jboss.org/author/pages/diffpagesbyversion.action?pageId=18646297&revisedVersion=15&originalVersion=14">View Changes</a>
|
<a href="https://docs.jboss.org/author/display/TEIID/Query+Plans?showComments=true&showCommentArea=true#addcomment">Add Comment</a>
</div>
</div>
</div>
</div>
</div>
</body>
</html>