[
https://issues.apache.org/jira/browse/HIVE-25285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18094272#comment-18094272
]
Hemanth Umashankar edited comment on HIVE-25285 at 7/7/26 4:13 PM:
-------------------------------------------------------------------
I spent some time investigating whether
{code:java}
HiveProjectJoinTransposeRule{code}
can be replaced with Calcite's
{code:java}
ProjectJoinTransposeRule {code}
directly.
As an experiment, I replaced the Hive rule with Calcite's default rule without
making any other code changes.
A few things I observed:
* The two implementations are not identical. Hive's rule has some additional
logic (for example, it skips {{SEMI}} and {{ANTI}} joins) that isn't present in
Calcite's default implementation.
* After replacing the rule, {{cbo_proj_join_transpose.q}} ran successfully but
produced a different CBO plan than the expected output.
* I also tried running {{semijoin.q}} and {{{}antijoin.q{}}}, and both showed
output differences after the replacement.
* While looking through the history of {{{}HiveProjectJoinTransposeRule{}}}, I
noticed that the {{SEMI}} join check existed originally, and support for
{{ANTI}} joins was added later. This makes me think these differences were
introduced intentionally rather than the Hive rule simply being an old copy of
Calcite's implementation.
Based on what I've investigated so far, it doesn't look like this is a
straightforward replacement. I'm still trying to understand whether these
differences are only optimizer plan changes or whether there's Hive-specific
behavior that still needs to be preserved. If anyone has additional context,
I'd really appreciate it.
was (Author: JIRAUSER312388):
I spent some time investigating whether \{{}}
{code:java}
HiveProjectJoinTransposeRule{code}
can be replaced with Calcite's \{{}}
{code:java}
ProjectJoinTransposeRule {code}
directly.
As an experiment, I replaced the Hive rule with Calcite's default rule without
making any other code changes.
A few things I observed:
* The two implementations are not identical. Hive's rule has some additional
logic (for example, it skips {{SEMI}} and {{ANTI}} joins) that isn't present in
Calcite's default implementation.
* After replacing the rule, {{cbo_proj_join_transpose.q}} ran successfully but
produced a different CBO plan than the expected output.
* I also tried running {{semijoin.q}} and {{{}antijoin.q{}}}, and both showed
output differences after the replacement.
* While looking through the history of {{{}HiveProjectJoinTransposeRule{}}}, I
noticed that the {{SEMI}} join check existed originally, and support for
{{ANTI}} joins was added later. This makes me think these differences were
introduced intentionally rather than the Hive rule simply being an old copy of
Calcite's implementation.
Based on what I've investigated so far, it doesn't look like this is a
straightforward replacement. I'm still trying to understand whether these
differences are only optimizer plan changes or whether there's Hive-specific
behavior that still needs to be preserved. If anyone has additional context,
I'd really appreciate it.
> Retire HiveProjectJoinTransposeRule
> -----------------------------------
>
> Key: HIVE-25285
> URL: https://issues.apache.org/jira/browse/HIVE-25285
> Project: Hive
> Issue Type: Improvement
> Reporter: Zoltan Haindrich
> Assignee: Hemanth Umashankar
> Priority: Major
> Labels: newbie
>
> we don't neccessary need our own rule anymore - a plain
> ProjectJoinTransposeRule could probably work
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
