[
https://issues.apache.org/jira/browse/TRAFODION-2758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16188531#comment-16188531
]
ASF GitHub Bot commented on TRAFODION-2758:
-------------------------------------------
Github user selvaganesang commented on a diff in the pull request:
https://github.com/apache/incubator-trafodion/pull/1250#discussion_r142212229
--- Diff: core/sql/optimizer/RelExpr.cpp ---
@@ -1078,7 +1078,33 @@ void RelExpr::pushDownGenericUpdateRootOutputs(
const ValueIdSet &outputs)
//QSTUFF
void RelExpr::needSortedNRows(NABoolean val)
-{
+{
+ // The operators listed below can create OR propogate a GET_N
+ // request. Other operatots will turn a GET_N request into GET_ALL
+ // There are a few exceptions like right side of NJ for semi join etc.
+ // but these are not relevant for FirstN sort
+ // This method should only in the generator since we are using
+ // physical node types.
+ OperatorTypeEnum operatorType = getOperatorType();
+ if ((operatorType != REL_FIRST_N) &&
+ (operatorType != REL_EXCHANGE) &&
+ (operatorType != REL_MERGE_UNION) &&
+ (operatorType != REL_PROBE_CACHE) &&
+ (operatorType != REL_ROOT) &&
+ (operatorType != REL_LEFT_NESTED_JOIN) &&
+ (operatorType != REL_LEFT_TSJ) &&
+ (operatorType != REL_MAP_VALUEIDS))
+ return ;
+
--- End diff --
This code looks ok. Do you think it will be easy to understand if this
condition is changed to use the operators that turns GET_N request to GET_ALL?
First there should be only handful operators that would turn GET_N request to
GET_ALL and there is less probable to add an operator that would turn GET_N to
GET_ALL
> Sort operator that uses TopN sort at runtime is not accurately determined at
> compile time
> -----------------------------------------------------------------------------------------
>
> Key: TRAFODION-2758
> URL: https://issues.apache.org/jira/browse/TRAFODION-2758
> Project: Apache Trafodion
> Issue Type: Bug
> Components: sql-cmp
> Affects Versions: 2.2-incubating
> Reporter: Suresh Subbiah
> Assignee: Suresh Subbiah
> Priority: Minor
>
> When a query has FIRST N clause along with an ORDER BY, the resultannt Sort
> operator is enable to do TopN optimization. The compiler needs to be aware of
> this so that memory can be shared appropriately between all big memory
> operators in the query. There are some flaws in the logic the compiler is
> using to determine if a sort is TopN enabled. Currently the compiler thinks
> all sort operators in the FirstN query are TopN enabled. This is incorrect,
> only the first Sort, when traversing the query tree downwards from FirstN
> will be enabled for this optimization, and that too with certain restrictions.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
