[
https://issues.apache.org/jira/browse/TRAFODION-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14945399#comment-14945399
]
ASF GitHub Bot commented on TRAFODION-25:
-----------------------------------------
Github user DaveBirdsall commented on a diff in the pull request:
https://github.com/apache/incubator-trafodion/pull/102#discussion_r41294553
--- Diff: core/sql/optimizer/TransRule.cpp ---
@@ -3287,6 +3287,15 @@ NABoolean TSJRule::topMatch (RelExpr * expr,
((updateExpr->getOperatorType() == REL_UNARY_DELETE) &&
updateExpr->isMtsStatement()))
return FALSE;
+ // It is not semantically correct to convert a MERGE having a
+ // "NOT MATCHED" action to a TSJ, since the former has right
+ // join semantics. (If we converted here to a TSJ, a non-matching
+ // row would not be returned by the outer child scan node, so
+ // the inner child merge node would never see it and hence the
+ // "NOT MATCHED" logic would not be activiated.)
+ if (updateExpr->isMerge() && updateExpr->insertValues())
--- End diff --
Yes, a TSJ for index maintenance still occurs. That is introduced by the
Binder, before we get to this code. This code deals with a different issue.
When we parse an UPDATE or DELETE statement, the Parser creates a Scan node
underneath the Update or Delete node. This rule allows the optimizer to
transform that to a TSJ(Scan,Update/Delete). (The alternative plan simply clips
off the Scan and an Update/Delete node by itself remains.) For MERGE with a NOT
MATCHED clause, the TSJ transformation gives an incorrect plan.
> Insert, delete and update operators should use specialized cost method
> -----------------------------------------------------------------------
>
> Key: TRAFODION-25
> URL: https://issues.apache.org/jira/browse/TRAFODION-25
> Project: Apache Trafodion
> Issue Type: Bug
> Reporter: Qifan Chen
> Assignee: David Wayne Birdsall
> Labels: performance
>
> In Trafodion, insert, delete and update operators do not use a specialized
> cost method that model the true operation involved.
> As a result, these operators can be assigned a zero cost and the query plan
> may not be optimal. In one example, a delete query against a partitioned
> table may get a serial plan.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
