[
https://issues.apache.org/jira/browse/DRILL-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15325176#comment-15325176
]
Jinfeng Ni commented on DRILL-4715:
-----------------------------------
AFAIK, it's not caused by lacking support of subexpression level. It's block vs
expressions. In Aditya's work, the breakup happens at block level, assuming
each expression will go into a separate block. CSE puts all the expressions
for some operators (project,) into one block. That essentially disable Aditya's
checking, since the method will have only one block.
[1]
https://github.com/apache/drill/blob/master/exec/java-exec/src/main/java/org/apache/drill/exec/expr/ClassGenerator.java#L222-L226
[2]
https://github.com/apache/drill/blob/master/exec/java-exec/src/main/java/org/apache/drill/exec/expr/ClassGenerator.java#L254
> Java compilation error for a query with large number of expressions
> -------------------------------------------------------------------
>
> Key: DRILL-4715
> URL: https://issues.apache.org/jira/browse/DRILL-4715
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Codegen
> Reporter: Jinfeng Ni
>
> The following query would hit compilation error, when Drill generates and
> compiles the run-time code.
> Q1 :
> {code}
> select expr1, expr2, expr3, ...., exprN
> from table
> {code}
> In Q1, expr1, expr2, ..., exprN are non-trivial expression (in stead of
> simply column reference), and N is big enough, then the run-time generated
> code may have a method which goes beyond the 64k limit imposed by JVM.
> This seems to be a regression from DRILL-3912 (Common subexpression
> elimination). CSE tries to put as many expressions in one block as possible,
> to detect and eliminate as many CSE as possible. However, this implies we may
> end up with big method with compilation error.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
