[
https://issues.apache.org/jira/browse/HIVE-28907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18105935#comment-18105935
]
Stamatis Zampetakis commented on HIVE-28907:
--------------------------------------------
After the upgrade to calcite 1.42.0 (HIVE-29641) the
HivePointLookupOptimizerRule has more redundancy since the RexSimplify logic
was enhanced with more transformations exploiting the SEARCH operator.
> Rework HivePointLookupOptimizerRule to drop redundant logic
> -----------------------------------------------------------
>
> Key: HIVE-28907
> URL: https://issues.apache.org/jira/browse/HIVE-28907
> Project: Hive
> Issue Type: Improvement
> Components: CBO
> Reporter: Stamatis Zampetakis
> Assignee: Stamatis Zampetakis
> Priority: Major
>
> The HivePointLookupOptimizerRule (introduced in HIVE-11424) is used to
> transform OR clauses into IN and BETWEEN expressions. The main reason for
> introducing this rule was to normalize, simplify, and fold expressions by
> picking a convenient representation.
> In CALCITE-4173, the SEARCH operator was introduced as an abstraction that
> encompasses IN, BETWEEN, and various other range conditions. The built-in
> simplification logic (RexSimplify) was enhanced to collapse many kind of
> range conditions and IN, BETWEEN, predicates to SEARCH.
> Currently, the RexSimplify and HivePointLookupOptimizerRule have a lot of
> overlapping logic making the rule redundant for the most part.
> Moreover, the rule introduces Hive specific IN, BETWEEN operators that may
> block other optimizations from triggering and cannot be collapsed together
> with the SEARCH operator.
> The rule should be reworked to remove duplicate logic and ensure that there
> is smooth integration with the SEARCH operator to reduce compilation time and
> provide better plans.
> It may be feasible to remove the rule altogether. If not then we should check
> if the Hive specific logic can be merged into RexSimplify.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
