[
https://issues.apache.org/jira/browse/DRILL-3912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14964301#comment-14964301
]
ASF GitHub Bot commented on DRILL-3912:
---------------------------------------
Github user jinfengni commented on the pull request:
https://github.com/apache/drill/pull/189#issuecomment-149385017
Seems to me this pull request would remove the common subexpression
elimination(CSE) for Project and Filter only; it would not do CSE for other
operators, like Join, Aggregation, Union, etc.
I understand that the Union-type work would highly require CSE in
Project/Filter. But will Union-type work would also require CSE in other
operators?
If this JIRA only targets for Project/Filter, I think it would make sense
to explicitly specify this scope in the JIRA. Otherwise, people would expect
CSE would happen to all Drill's relation operator, which is not true.
Another question I have is : how easy is it to extend this patch to include
CSE support for other operators? I tried to enable CSE for all operators.
Turns out that bunch of unit testcase would fail.
> Common subexpression elimination in code generation
> ---------------------------------------------------
>
> Key: DRILL-3912
> URL: https://issues.apache.org/jira/browse/DRILL-3912
> Project: Apache Drill
> Issue Type: Bug
> Reporter: Steven Phillips
> Assignee: Jinfeng Ni
>
> Drill currently will evaluate the full expression tree, even if there are
> redundant subtrees. Many of these redundant evaluations can be eliminated by
> reusing the results from previously evaluated expression trees.
> For example,
> {code}
> select a + 1, (a + 1)* (a - 1) from t
> {code}
> Will compute the entire (a + 1) expression twice. With CSE, it will only be
> evaluated once.
> The benefit will be reducing the work done when evaluating expressions, as
> well as reducing the amount of code that is generated, which could also lead
> to better JIT optimization.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
