[
https://issues.apache.org/jira/browse/TRAFODION-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14944279#comment-14944279
]
ASF GitHub Bot commented on TRAFODION-25:
-----------------------------------------
Github user sureshsubbiah commented on a diff in the pull request:
https://github.com/apache/incubator-trafodion/pull/102#discussion_r41212885
--- 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 --
I am assuming that when a TSJ is used for IndexMaintenence or to to flow
rows from a TupleList or a source select it should be acceptable. Are those
cases excluded somehow by this restriction?
> 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)
