[jira] [Commented] (DRILL-7306) Disable "fast schema" batch for new scan framework
[ https://issues.apache.org/jira/browse/DRILL-7306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16870808#comment-16870808 ] ASF GitHub Bot commented on DRILL-7306: --- paul-rogers commented on pull request #1813: DRILL-7306: Disable schema-only batch for new scan framework URL: https://github.com/apache/drill/pull/1813 The EVF framework is set up to return a "fast schema" empty batch with only schema as its first batch because, when the code was written, it seemed that's how we wanted operators to work. However, DRILL-7305 notes that many operators cannot handle empty batches. Since the empty-batch bugs show that Drill does not, in fact, provide a "fast schema" batch, this ticket asks to disable the feature in the new scan framework. The feature is disabled with a config option; it can be re-enabled if ever it is needed. Old tests validate the original schema-batch mode, new tests added to validate the no-schema-batch mode. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Disable "fast schema" batch for new scan framework > -- > > Key: DRILL-7306 > URL: https://issues.apache.org/jira/browse/DRILL-7306 > Project: Apache Drill > Issue Type: Bug >Affects Versions: 1.16.0 >Reporter: Paul Rogers >Assignee: Paul Rogers >Priority: Major > Fix For: 1.17.0 > > > The EVF framework is set up to return a "fast schema" empty batch with only > schema as its first batch because, when the code was written, it seemed > that's how we wanted operators to work. However, DRILL-7305 notes that many > operators cannot handle empty batches. > Since the empty-batch bugs show that Drill does not, in fact, provide a "fast > schema" batch, this ticket asks to disable the feature in the new scan > framework. The feature is disabled with a config option; it can be re-enabled > if ever it is needed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DRILL-7305) Multiple operators do not handle empty batches
[
https://issues.apache.org/jira/browse/DRILL-7305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Rogers updated DRILL-7305:
---
Description:
While testing the new "EVF" framework, it was found that multiple operators
incorrectly handle empty batches. The EVF framework is set up to return a "fast
schema" empty batch with only schema as its first batch. It turns out that many
operators fail with problems such as:
* Failure to set the value counts in the output container
* Fail to initialize the offset vector position 0 to 0 for variable-width or
repeated vectors
And so on.
Partial fixes are in the JSON reader PR.
For now, the easiest work-around is to disable the "fast schema" path in the
EVF: DRILL-7306.
To discover the remaining issues, enable the
{{ScanOrchestratorBuilder.enableSchemaBatch}} option and run unit tests. You
can use the {{VectorChecker}} and {{VectorAccessorUtilities.verify()}} methods
to check state. Insert a call to {{verify()}} in each "next" method: verify the
incoming and outgoing batches. The checker only verifies a few vector types;
but these are enough to show many problems.
was:
While testing the new "EVF" framework, it was found that multiple operators
incorrectly handle empty batches. The EVF framework is set up to return a "fast
schema" empty batch with only schema as its first batch. It turns out that many
operators fail with problems such as:
* Failure to set the value counts in the output container
* Fail to initialize the offset vector position 0 to 0 for variable-width or
repeated vectors
And so on.
Partial fixes are in the JSON reader PR.
For now, the easiest work-around is to disable the "fast schema" path in the
EVF: DRILL-7306.
> Multiple operators do not handle empty batches
> --
>
> Key: DRILL-7305
> URL: https://issues.apache.org/jira/browse/DRILL-7305
> Project: Apache Drill
> Issue Type: Bug
>Affects Versions: 1.16.0
>Reporter: Paul Rogers
>Priority: Major
>
> While testing the new "EVF" framework, it was found that multiple operators
> incorrectly handle empty batches. The EVF framework is set up to return a
> "fast schema" empty batch with only schema as its first batch. It turns out
> that many operators fail with problems such as:
> * Failure to set the value counts in the output container
> * Fail to initialize the offset vector position 0 to 0 for variable-width or
> repeated vectors
> And so on.
> Partial fixes are in the JSON reader PR.
> For now, the easiest work-around is to disable the "fast schema" path in the
> EVF: DRILL-7306.
> To discover the remaining issues, enable the
> {{ScanOrchestratorBuilder.enableSchemaBatch}} option and run unit tests. You
> can use the {{VectorChecker}} and {{VectorAccessorUtilities.verify()}}
> methods to check state. Insert a call to {{verify()}} in each "next" method:
> verify the incoming and outgoing batches. The checker only verifies a few
> vector types; but these are enough to show many problems.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DRILL-7305) Multiple operators do not handle empty batches
[ https://issues.apache.org/jira/browse/DRILL-7305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Rogers updated DRILL-7305: --- Description: While testing the new "EVF" framework, it was found that multiple operators incorrectly handle empty batches. The EVF framework is set up to return a "fast schema" empty batch with only schema as its first batch. It turns out that many operators fail with problems such as: * Failure to set the value counts in the output container * Fail to initialize the offset vector position 0 to 0 for variable-width or repeated vectors And so on. Partial fixes are in the JSON reader PR. For now, the easiest work-around is to disable the "fast schema" path in the EVF: DRILL-7306. was: While testing the new "EVF" framework, it was found that multiple operators incorrectly handle empty batches. The EVF framework is set up to return a "fast schema" empty batch with only schema as its first batch. It turns out that many operators fail with problems such as: * Failure to set the value counts in the output container * Fail to initialize the offset vector position 0 to 0 for variable-width or repeated vectors And so on. Partial fixes are in the JSON reader PR. For now, the easiest work-around is to disable the "fast schema" path in the EVF. > Multiple operators do not handle empty batches > -- > > Key: DRILL-7305 > URL: https://issues.apache.org/jira/browse/DRILL-7305 > Project: Apache Drill > Issue Type: Bug >Affects Versions: 1.16.0 >Reporter: Paul Rogers >Priority: Major > > While testing the new "EVF" framework, it was found that multiple operators > incorrectly handle empty batches. The EVF framework is set up to return a > "fast schema" empty batch with only schema as its first batch. It turns out > that many operators fail with problems such as: > * Failure to set the value counts in the output container > * Fail to initialize the offset vector position 0 to 0 for variable-width or > repeated vectors > And so on. > Partial fixes are in the JSON reader PR. > For now, the easiest work-around is to disable the "fast schema" path in the > EVF: DRILL-7306. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (DRILL-7306) Disable "fast schema" batch for new scan framework
Paul Rogers created DRILL-7306: -- Summary: Disable "fast schema" batch for new scan framework Key: DRILL-7306 URL: https://issues.apache.org/jira/browse/DRILL-7306 Project: Apache Drill Issue Type: Bug Affects Versions: 1.16.0 Reporter: Paul Rogers Assignee: Paul Rogers Fix For: 1.17.0 The EVF framework is set up to return a "fast schema" empty batch with only schema as its first batch because, when the code was written, it seemed that's how we wanted operators to work. However, DRILL-7305 notes that many operators cannot handle empty batches. Since the empty-batch bugs show that Drill does not, in fact, provide a "fast schema" batch, this ticket asks to disable the feature in the new scan framework. The feature is disabled with a config option; it can be re-enabled if ever it is needed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (DRILL-7305) Multiple operators do not handle empty batches
Paul Rogers created DRILL-7305: -- Summary: Multiple operators do not handle empty batches Key: DRILL-7305 URL: https://issues.apache.org/jira/browse/DRILL-7305 Project: Apache Drill Issue Type: Bug Affects Versions: 1.16.0 Reporter: Paul Rogers While testing the new "EVF" framework, it was found that multiple operators incorrectly handle empty batches. The EVF framework is set up to return a "fast schema" empty batch with only schema as its first batch. It turns out that many operators fail with problems such as: * Failure to set the value counts in the output container * Fail to initialize the offset vector position 0 to 0 for variable-width or repeated vectors And so on. Partial fixes are in the JSON reader PR. For now, the easiest work-around is to disable the "fast schema" path in the EVF. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DRILL-7297) Query hangs in planning stage when Error is thrown
[
https://issues.apache.org/jira/browse/DRILL-7297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16870723#comment-16870723
]
ASF GitHub Bot commented on DRILL-7297:
---
amansinha100 commented on pull request #1811: DRILL-7297: Query hangs in
planning stage when Error is thrown
URL: https://github.com/apache/drill/pull/1811
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Query hangs in planning stage when Error is thrown
> --
>
> Key: DRILL-7297
> URL: https://issues.apache.org/jira/browse/DRILL-7297
> Project: Apache Drill
> Issue Type: Bug
>Affects Versions: 1.16.0
>Reporter: Volodymyr Vysotskyi
>Assignee: Volodymyr Vysotskyi
>Priority: Major
> Labels: ready-to-commit
> Fix For: 1.17.0
>
>
> Query hangs in the planning stage when Error (not OOM or AssertionError) is
> thrown during query planning. After canceling the query it will stay in
> Cancellation Requested state.
> Such error may be thrown due to the mistake in the code, including UDF. Since
> the user may provide custom UDFs, Drill should be able to handle such cases
> also.
> Steps to reproduce this issue:
> 1. Create UDF which throws Error in either {{eval()}} or {{setup()}} method
> (instructions how to create custom UDF may be found
> [here|https://drill.apache.org/docs/tutorial-develop-a-simple-function/].
> 2. Register custom UDF which throws an error (instruction is
> [here|https://drill.apache.org/docs/adding-custom-functions-to-drill-introduction/]).
> 3. Run the query with this UDF.
> After submitting the query, the following stack trace is printed:
> {noformat}
> Exception in thread "drill-executor-1" java.lang.Error
> at
> org.apache.drill.contrib.function.FunctionExample.setup(FunctionExample.java:19)
> at
> org.apache.drill.exec.expr.fn.interpreter.InterpreterEvaluator.evaluateFunction(InterpreterEvaluator.java:139)
> at
> org.apache.drill.exec.expr.fn.interpreter.InterpreterEvaluator$EvalVisitor.visitFunctionHolderExpression(InterpreterEvaluator.java:355)
> at
> org.apache.drill.exec.expr.fn.interpreter.InterpreterEvaluator$EvalVisitor.visitFunctionHolderExpression(InterpreterEvaluator.java:204)
> at
> org.apache.drill.common.expression.FunctionHolderExpression.accept(FunctionHolderExpression.java:53)
> at
> org.apache.drill.exec.expr.fn.interpreter.InterpreterEvaluator.evaluateConstantExpr(InterpreterEvaluator.java:70)
> at
> org.apache.drill.exec.planner.logical.DrillConstExecutor.reduce(DrillConstExecutor.java:152)
> at
> org.apache.calcite.rel.rules.ReduceExpressionsRule.reduceExpressionsInternal(ReduceExpressionsRule.java:620)
> at
> org.apache.calcite.rel.rules.ReduceExpressionsRule.reduceExpressions(ReduceExpressionsRule.java:541)
> at
> org.apache.calcite.rel.rules.ReduceExpressionsRule$ProjectReduceExpressionsRule.onMatch(ReduceExpressionsRule.java:288)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:212)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:643)
> at
> org.apache.calcite.tools.Programs$RuleSetProgram.run(Programs.java:339)
> at
> org.apache.drill.exec.planner.sql.handlers.DefaultSqlHandler.transform(DefaultSqlHandler.java:430)
> at
> org.apache.drill.exec.planner.sql.handlers.DefaultSqlHandler.transform(DefaultSqlHandler.java:370)
> at
> org.apache.drill.exec.planner.sql.handlers.DefaultSqlHandler.convertToRawDrel(DefaultSqlHandler.java:250)
> at
> org.apache.drill.exec.planner.sql.handlers.DefaultSqlHandler.convertToDrel(DefaultSqlHandler.java:319)
> at
> org.apache.drill.exec.planner.sql.handlers.DefaultSqlHandler.getPlan(DefaultSqlHandler.java:177)
> at
> org.apache.drill.exec.planner.sql.DrillSqlWorker.getQueryPlan(DrillSqlWorker.java:226)
> at
> org.apache.drill.exec.planner.sql.DrillSqlWorker.convertPlan(DrillSqlWorker.java:124)
> at
> org.apache.drill.exec.planner.sql.DrillSqlWorker.getPlan(DrillSqlWorker.java:90)
> at org.apache.drill.exec.work.foreman.Foreman.runSQL(Foreman.java:593)
> at org.apache.drill.exec.work.foreman.Foreman.run(Foreman.java:276)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> 4. Check that query is still in progress state, cancel
[jira] [Commented] (DRILL-7268) Read Hive array with parquet native reader
[ https://issues.apache.org/jira/browse/DRILL-7268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16870722#comment-16870722 ] ASF GitHub Bot commented on DRILL-7268: --- amansinha100 commented on pull request #1805: DRILL-7268: Read Hive array with parquet native reader URL: https://github.com/apache/drill/pull/1805 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Read Hive array with parquet native reader > -- > > Key: DRILL-7268 > URL: https://issues.apache.org/jira/browse/DRILL-7268 > Project: Apache Drill > Issue Type: Sub-task >Reporter: Igor Guzenko >Assignee: Igor Guzenko >Priority: Major > Labels: ready-to-commit > Fix For: 1.17.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DRILL-7302) Bump Apache Avro from 1.8.2 to 1.9.0
[ https://issues.apache.org/jira/browse/DRILL-7302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16870724#comment-16870724 ] ASF GitHub Bot commented on DRILL-7302: --- amansinha100 commented on pull request #1812: DRILL-7302: Bump Apache Avro to 1.9.0 URL: https://github.com/apache/drill/pull/1812 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Bump Apache Avro from 1.8.2 to 1.9.0 > > > Key: DRILL-7302 > URL: https://issues.apache.org/jira/browse/DRILL-7302 > Project: Apache Drill > Issue Type: Improvement >Reporter: Fokko Driesprong >Priority: Major > Labels: ready-to-commit > Fix For: 1.17.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DRILL-7302) Bump Apache Avro from 1.8.2 to 1.9.0
[ https://issues.apache.org/jira/browse/DRILL-7302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16870648#comment-16870648 ] Aman Sinha commented on DRILL-7302: --- [~Fokko] thanks for the contribution. For some reason I am unable to assign the JIRA to you. Pls assign it to yourself. > Bump Apache Avro from 1.8.2 to 1.9.0 > > > Key: DRILL-7302 > URL: https://issues.apache.org/jira/browse/DRILL-7302 > Project: Apache Drill > Issue Type: Improvement >Reporter: Fokko Driesprong >Priority: Major > Labels: ready-to-commit > Fix For: 1.17.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DRILL-7297) Query hangs in planning stage when Error is thrown
[
https://issues.apache.org/jira/browse/DRILL-7297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aman Sinha updated DRILL-7297:
--
Reviewer: Bohdan Kazydub
> Query hangs in planning stage when Error is thrown
> --
>
> Key: DRILL-7297
> URL: https://issues.apache.org/jira/browse/DRILL-7297
> Project: Apache Drill
> Issue Type: Bug
>Affects Versions: 1.16.0
>Reporter: Volodymyr Vysotskyi
>Assignee: Volodymyr Vysotskyi
>Priority: Major
> Labels: ready-to-commit
> Fix For: 1.17.0
>
>
> Query hangs in the planning stage when Error (not OOM or AssertionError) is
> thrown during query planning. After canceling the query it will stay in
> Cancellation Requested state.
> Such error may be thrown due to the mistake in the code, including UDF. Since
> the user may provide custom UDFs, Drill should be able to handle such cases
> also.
> Steps to reproduce this issue:
> 1. Create UDF which throws Error in either {{eval()}} or {{setup()}} method
> (instructions how to create custom UDF may be found
> [here|https://drill.apache.org/docs/tutorial-develop-a-simple-function/].
> 2. Register custom UDF which throws an error (instruction is
> [here|https://drill.apache.org/docs/adding-custom-functions-to-drill-introduction/]).
> 3. Run the query with this UDF.
> After submitting the query, the following stack trace is printed:
> {noformat}
> Exception in thread "drill-executor-1" java.lang.Error
> at
> org.apache.drill.contrib.function.FunctionExample.setup(FunctionExample.java:19)
> at
> org.apache.drill.exec.expr.fn.interpreter.InterpreterEvaluator.evaluateFunction(InterpreterEvaluator.java:139)
> at
> org.apache.drill.exec.expr.fn.interpreter.InterpreterEvaluator$EvalVisitor.visitFunctionHolderExpression(InterpreterEvaluator.java:355)
> at
> org.apache.drill.exec.expr.fn.interpreter.InterpreterEvaluator$EvalVisitor.visitFunctionHolderExpression(InterpreterEvaluator.java:204)
> at
> org.apache.drill.common.expression.FunctionHolderExpression.accept(FunctionHolderExpression.java:53)
> at
> org.apache.drill.exec.expr.fn.interpreter.InterpreterEvaluator.evaluateConstantExpr(InterpreterEvaluator.java:70)
> at
> org.apache.drill.exec.planner.logical.DrillConstExecutor.reduce(DrillConstExecutor.java:152)
> at
> org.apache.calcite.rel.rules.ReduceExpressionsRule.reduceExpressionsInternal(ReduceExpressionsRule.java:620)
> at
> org.apache.calcite.rel.rules.ReduceExpressionsRule.reduceExpressions(ReduceExpressionsRule.java:541)
> at
> org.apache.calcite.rel.rules.ReduceExpressionsRule$ProjectReduceExpressionsRule.onMatch(ReduceExpressionsRule.java:288)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:212)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:643)
> at
> org.apache.calcite.tools.Programs$RuleSetProgram.run(Programs.java:339)
> at
> org.apache.drill.exec.planner.sql.handlers.DefaultSqlHandler.transform(DefaultSqlHandler.java:430)
> at
> org.apache.drill.exec.planner.sql.handlers.DefaultSqlHandler.transform(DefaultSqlHandler.java:370)
> at
> org.apache.drill.exec.planner.sql.handlers.DefaultSqlHandler.convertToRawDrel(DefaultSqlHandler.java:250)
> at
> org.apache.drill.exec.planner.sql.handlers.DefaultSqlHandler.convertToDrel(DefaultSqlHandler.java:319)
> at
> org.apache.drill.exec.planner.sql.handlers.DefaultSqlHandler.getPlan(DefaultSqlHandler.java:177)
> at
> org.apache.drill.exec.planner.sql.DrillSqlWorker.getQueryPlan(DrillSqlWorker.java:226)
> at
> org.apache.drill.exec.planner.sql.DrillSqlWorker.convertPlan(DrillSqlWorker.java:124)
> at
> org.apache.drill.exec.planner.sql.DrillSqlWorker.getPlan(DrillSqlWorker.java:90)
> at org.apache.drill.exec.work.foreman.Foreman.runSQL(Foreman.java:593)
> at org.apache.drill.exec.work.foreman.Foreman.run(Foreman.java:276)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> 4. Check that query is still in progress state, cancel query.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DRILL-7297) Query hangs in planning stage when Error is thrown
[
https://issues.apache.org/jira/browse/DRILL-7297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16870638#comment-16870638
]
ASF GitHub Bot commented on DRILL-7297:
---
amansinha100 commented on issue #1811: DRILL-7297: Query hangs in planning
stage when Error is thrown
URL: https://github.com/apache/drill/pull/1811#issuecomment-504782828
+1
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Query hangs in planning stage when Error is thrown
> --
>
> Key: DRILL-7297
> URL: https://issues.apache.org/jira/browse/DRILL-7297
> Project: Apache Drill
> Issue Type: Bug
>Affects Versions: 1.16.0
>Reporter: Volodymyr Vysotskyi
>Assignee: Volodymyr Vysotskyi
>Priority: Major
> Labels: ready-to-commit
> Fix For: 1.17.0
>
>
> Query hangs in the planning stage when Error (not OOM or AssertionError) is
> thrown during query planning. After canceling the query it will stay in
> Cancellation Requested state.
> Such error may be thrown due to the mistake in the code, including UDF. Since
> the user may provide custom UDFs, Drill should be able to handle such cases
> also.
> Steps to reproduce this issue:
> 1. Create UDF which throws Error in either {{eval()}} or {{setup()}} method
> (instructions how to create custom UDF may be found
> [here|https://drill.apache.org/docs/tutorial-develop-a-simple-function/].
> 2. Register custom UDF which throws an error (instruction is
> [here|https://drill.apache.org/docs/adding-custom-functions-to-drill-introduction/]).
> 3. Run the query with this UDF.
> After submitting the query, the following stack trace is printed:
> {noformat}
> Exception in thread "drill-executor-1" java.lang.Error
> at
> org.apache.drill.contrib.function.FunctionExample.setup(FunctionExample.java:19)
> at
> org.apache.drill.exec.expr.fn.interpreter.InterpreterEvaluator.evaluateFunction(InterpreterEvaluator.java:139)
> at
> org.apache.drill.exec.expr.fn.interpreter.InterpreterEvaluator$EvalVisitor.visitFunctionHolderExpression(InterpreterEvaluator.java:355)
> at
> org.apache.drill.exec.expr.fn.interpreter.InterpreterEvaluator$EvalVisitor.visitFunctionHolderExpression(InterpreterEvaluator.java:204)
> at
> org.apache.drill.common.expression.FunctionHolderExpression.accept(FunctionHolderExpression.java:53)
> at
> org.apache.drill.exec.expr.fn.interpreter.InterpreterEvaluator.evaluateConstantExpr(InterpreterEvaluator.java:70)
> at
> org.apache.drill.exec.planner.logical.DrillConstExecutor.reduce(DrillConstExecutor.java:152)
> at
> org.apache.calcite.rel.rules.ReduceExpressionsRule.reduceExpressionsInternal(ReduceExpressionsRule.java:620)
> at
> org.apache.calcite.rel.rules.ReduceExpressionsRule.reduceExpressions(ReduceExpressionsRule.java:541)
> at
> org.apache.calcite.rel.rules.ReduceExpressionsRule$ProjectReduceExpressionsRule.onMatch(ReduceExpressionsRule.java:288)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:212)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:643)
> at
> org.apache.calcite.tools.Programs$RuleSetProgram.run(Programs.java:339)
> at
> org.apache.drill.exec.planner.sql.handlers.DefaultSqlHandler.transform(DefaultSqlHandler.java:430)
> at
> org.apache.drill.exec.planner.sql.handlers.DefaultSqlHandler.transform(DefaultSqlHandler.java:370)
> at
> org.apache.drill.exec.planner.sql.handlers.DefaultSqlHandler.convertToRawDrel(DefaultSqlHandler.java:250)
> at
> org.apache.drill.exec.planner.sql.handlers.DefaultSqlHandler.convertToDrel(DefaultSqlHandler.java:319)
> at
> org.apache.drill.exec.planner.sql.handlers.DefaultSqlHandler.getPlan(DefaultSqlHandler.java:177)
> at
> org.apache.drill.exec.planner.sql.DrillSqlWorker.getQueryPlan(DrillSqlWorker.java:226)
> at
> org.apache.drill.exec.planner.sql.DrillSqlWorker.convertPlan(DrillSqlWorker.java:124)
> at
> org.apache.drill.exec.planner.sql.DrillSqlWorker.getPlan(DrillSqlWorker.java:90)
> at org.apache.drill.exec.work.foreman.Foreman.runSQL(Foreman.java:593)
> at org.apache.drill.exec.work.foreman.Foreman.run(Foreman.java:276)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> 4. Check that query is still in
