[
https://issues.apache.org/jira/browse/CALCITE-4623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17352187#comment-17352187
]
Julian Hyde commented on CALCITE-4623:
--------------------------------------
I don't see any reason to support SEMI. Remove it and see if anything breaks.
If there are no tests, we're better without it.
Reading the code, the {{perform}} method will not even get to that point. If
{{project != null}}, the projected fields will not intersect the fields from
the right (because a semi-join returns no fields from the right); if {{project
== null}}, then {{join.getJoinType().projectsRight()}} will return false.
Either way, the method will return.
There might be some point in a rule that matches a semi-{{Join}} whose right
input is an {{Aggregate}} and strips away that {{Aggregate}}. Maybe we already
do that.
> Review if SemiJoinRule shall / shall not match SEMI join
> --------------------------------------------------------
>
> Key: CALCITE-4623
> URL: https://issues.apache.org/jira/browse/CALCITE-4623
> Project: Calcite
> Issue Type: Task
> Components: core
> Affects Versions: 1.26.0
> Reporter: Ruben Q L
> Priority: Major
>
> Issue pointed out by [~zabetak] during the review of CALCITE-4621.
> Currently, SemiJoinRule (both {{CoreRules.JOIN_TO_SEMI_JOIN}} and
> {{CoreRules.PROJECT_TO_SEMI_JOIN}}) matches INNER, LEFT and SEMI join. This
> last join type seems a bit bizarre (why matching a SEMI join if the purpose
> of this rule is precisely generating one?).
> It seems that SEMI was introduced in the rule by the "big join design
> refactoring" (see CALCITE-2969 and
> [4809393|https://github.com/apache/calcite/commit/48093937ae4db179884d1111fa9d12e978e57e1f]).
> The purpose of this ticket is to confirm whether or not processing SEMI in
> SemiJoinRule makes sense (and if not, remove it).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
