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

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

                Author: ASF GitHub Bot
            Created on: 27/Mar/22 00:20
            Start Date: 27/Mar/22 00:20
    Worklog Time Spent: 10m 
      Work Description: github-actions[bot] closed pull request #2928:
URL: https://github.com/apache/hive/pull/2928


   


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

To unsubscribe, e-mail: gitbox-unsubscr...@hive.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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

    Worklog Id:     (was: 748288)
    Time Spent: 40m  (was: 0.5h)

> Introduce IN clauses at the very end of query planning
> ------------------------------------------------------
>
>                 Key: HIVE-25852
>                 URL: https://issues.apache.org/jira/browse/HIVE-25852
>             Project: Hive
>          Issue Type: Bug
>          Components: CBO
>    Affects Versions: 4.0.0
>            Reporter: Alessandro Solimando
>            Priority: Major
>              Labels: pull-request-available
>          Time Spent: 40m
>  Remaining Estimate: 0h
>
> Calcite "explodes" IN clauses into the equivalent OR form, and therefore it 
> does not handle such clauses in most of the codebase (notably in 
> _RexSimplify_).
> In Hive, the same happens, but _HivePointLookupOptimizerRule_ re-introduces 
> IN clauses, and it happens in _applyPreJoinOrderingTransforms_ phase, which 
> is pretty early and which mixes several other rules which might not fully 
> support IN (notably, _HiveReduceExpressionsRule_ which is based on 
> _RexSimplify_).
> The problem will become even harder in later versions of Calcite (current is 
> 1.25) based on SARG, which does not support IN clauses.
> IN clauses can be converted into efficient runtime operators, we therefore 
> want to keep them in the final plan, intuitively we just want this 
> translation to happen in a later step, in order to leave the rest of the 
> codebase (Hive and Calcite) unaware of IN clauses.
> The goal of the ticket is as follows:
> # re-convert the output expression of _HivePointLookupOptimizerRule_ into the 
> OR form (keep the logic as-is to benefit from the rule)
> # add a rule, in the last step of the planning process, that only converts 
> eligible OR expressions into IN clauses



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Reply via email to