[ 
https://issues.apache.org/jira/browse/HIVE-24601?focusedWorklogId=542864&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-542864
 ]

ASF GitHub Bot logged work on HIVE-24601:
-----------------------------------------

                Author: ASF GitHub Bot
            Created on: 27/Jan/21 14:26
            Start Date: 27/Jan/21 14:26
    Worklog Time Spent: 10m 
      Work Description: kgyrtkirk commented on a change in pull request #1875:
URL: https://github.com/apache/hive/pull/1875#discussion_r565349741



##########
File path: ql/src/java/org/apache/hadoop/hive/ql/parse/CalcitePlanner.java
##########
@@ -679,27 +680,15 @@ Operator genOPTree(ASTNode ast, PlannerContext 
plannerCtx) throws SemanticExcept
 
           // Determine if we should re-throw the exception OR if we try to 
mark plan as reAnayzeAST to retry
           // planning as non-CBO.
-          if (e instanceof CalciteSubquerySemanticException || e instanceof 
CalciteViewSemanticException
-              || e instanceof CalciteSubqueryRuntimeException) {
-            // Non-CBO path for CalciteSubquerySemanticException fails with 
completely different error
-            // and masks the original failure.
-            // Non-CBO path for CalciteViewSemanticException would fail in a 
similar way as CBO path.
-            throw new SemanticException(e);
-          }
-
-          boolean isHiveTest = conf.getBoolVar(ConfVars.HIVE_IN_TEST);
-          // At this point we retry with CBO off:
-          // 1) If this is not test mode (common case)
-          // 2) If we are in test mode and we are missing stats
-          // 3) if we are in test mode and a CalciteSemanticException is 
generated
-          reAnalyzeAST = (!isHiveTest || isMissingStats ||  e instanceof 
CalciteSemanticException);

Review comment:
       thank you for the explanation - yes it will be good
   
   about the `RuntimeException` stuff - I think in case we encounter something 
unknown; we should just stop the show.
   But because the approach is to blacklist some exception types - and retry 
everything else. Which probably aligns better to what our users want most of 
the time - get the resultset one way or the other.




----------------------------------------------------------------
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


Issue Time Tracking
-------------------

    Worklog Id:     (was: 542864)
    Time Spent: 2h 40m  (was: 2.5h)

> Control CBO fallback behavior via property
> ------------------------------------------
>
>                 Key: HIVE-24601
>                 URL: https://issues.apache.org/jira/browse/HIVE-24601
>             Project: Hive
>          Issue Type: Improvement
>            Reporter: Stamatis Zampetakis
>            Assignee: Stamatis Zampetakis
>            Priority: Major
>              Labels: pull-request-available
>          Time Spent: 2h 40m
>  Remaining Estimate: 0h
>
> When CBO optimizer fails there is a fallback mechanism(HIVE-7413) that will 
> retry to process the query using the legacy Hive optimizer. 
> There are use-cases where this behavior is not desirable notably for the 
> tests (HIVE-16058) but also for end users who would like to disable the 
> fall-back mechanism to avoid running problematic queries without realizing.
> The goal of this issue is to introduce a dedicated Hive property controlling 
> this behavior,{{hive.cbo.fallback.enable}}, for both tests and production. 
> The default value should be true and tests should run with this property set 
> to false. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to