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. Union All - There are no properties for this node, it just passes rows through from it's children. Join - Defines the join type, join criteria, and join strategy (merge or nested loop). Select - Select is a criteria evaluation filter node (WHERE / HAVING).
Window Function Project - Like a normal project, but includes window functions.
Typically created when executing an insert into view with a query expression. Insert Plan Execution - Similar to a project into, but executes a plan rather than a source query. Project Into - Like a normal project, but outputs rows into a target table. This does not alter the number of records returned. Project - Defines the columns returned from the node.
DATAGRIP EXECUTION PLAN UPDATE
ĭependent Procedure Access - Access a stored procedure on a source using multiple sets of input values.īatched Update - Processes a set of updates as a batch. A source query is sent to the connection factory associated with the source. The nodes for a relational query plan are:Īccess - Access a source. 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. Relational plans represent the processing plan that is composed of nodes representing building blocks of logical relational operations. Only in specific optimizations, such as dependent join, will the children of a join execute serially. In most other situation, child nodes may be executed in any order even in parallel. In a procedural context the ordering of child nodes implies the order of execution. 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.
DATAGRIP EXECUTION PLAN FULL
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.Ī query plan consists of a set of nodes organized in a tree structure. You will typically be interested in analyzing the textual form of the final processing plan. Presence of federated optimizations, such as dependent joins.Įnsure hints have the desired affects - see Hints and Options, hints in the FROM Clause, Subquery Optimization, and Federated Optimizations.Īll of the above information can be determined from the processing plan. Join algorithm used - merge, enhanced merge, nested loop, etc. Join ordering - typically influenced by costing Joins - as federated joins can be quite expensive Source pushdown - what parts of the query that got pushed to each sourceĮnsure that any predicates especially against indexes are pushed Once a query plan has been obtained you will most commonly be looking for:
0 kommentar(er)
