[
https://issues.apache.org/jira/browse/TRAFODION-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15613810#comment-15613810
]
ASF GitHub Bot commented on TRAFODION-2317:
-------------------------------------------
Github user zellerh commented on a diff in the pull request:
https://github.com/apache/incubator-trafodion/pull/794#discussion_r85455619
--- Diff: core/sql/executor/ExHdfsScan.cpp ---
@@ -1700,6 +1714,138 @@ char *
ExHdfsScanTcb::extractAndTransformAsciiSourceToSqlRow(int &err,
return NULL;
}
+void ExHdfsScanTcb::computeRangesAtRuntime()
--- End diff --
Yes, but doing so would be quite complex, since we would have to send the
data to the EPSs. Your proposal is somewhat related to Dave's proposal to
generate the temp table name at runtime - this would also require sending
information to the ESPs. So, maybe we can consider both of those together.
Because of the security holes with Hive tables, however, I'm wondering whether
we should try volatile tables first before making the Hive table solution
better.
> Implement relational operator for common subexpressions and transformation
> --------------------------------------------------------------------------
>
> Key: TRAFODION-2317
> URL: https://issues.apache.org/jira/browse/TRAFODION-2317
> Project: Apache Trafodion
> Issue Type: Sub-task
> Components: sql-cmp
> Affects Versions: 2.1-incubating
> Reporter: Hans Zeller
> Assignee: Hans Zeller
>
> This subtask provides the infrastructure for handling common subexpressions:
> - A relational CommonSubExprRef operator to track the locations of common
> subexpressions in the query tree.
> - Methods to analyze the common subexpressions in the tree and to determine
> whether a transformation is possible and what the temporary table would look
> like.
> - Methods to do the actual query tree transformation.
> - Some needed changes in bookkeeping and runtime.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
