[
https://issues.apache.org/jira/browse/TRAFODION-2758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16189184#comment-16189184
]
ASF GitHub Bot commented on TRAFODION-2758:
-------------------------------------------
Github user sureshsubbiah commented on a diff in the pull request:
https://github.com/apache/incubator-trafodion/pull/1250#discussion_r142300367
--- 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 --
Thank you for the review. I think there are more operators that change
GET_N to GET_ALL, than those that preserve a GET_N. I like to think of it as
most operators may need more than N rows to produce N rows (say a join or a
groupby). There are fewer that can guarantee N rows, every time they receive N
rows.
> 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)
