[
https://issues.apache.org/jira/browse/CALCITE-7232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18031242#comment-18031242
]
Steve Carlin commented on CALCITE-7232:
---------------------------------------
Deleted my first comment since I perhaps missed a nuance. But to quickly
address the isSimplified flag and whatever else is needed ...I still think it's
a good idea to put some information into the constructor (and I too am against
mutability, as I mentioned) to prevent multiple rules going through the
RexNodes trying to resimplify something that has already ben simplified. But
we can brush this aside, it should be in a separate Jira discussion.
I'm in on the LooseRex and PlanningRex. But I was thinking about this a little
more. I mean, the main issue this is addressing is to prevent BETWEEN, IN,
"=", "<", etc... being present when a rule is applied, I think?
But if we are saying IN is something "good" (which I absolutely believe it is),
then we need RexSimplify to support "IN -> SEARCH". This is mandatory, imo.
At that point and I think [~zabetak] was alluding to this, how is this
different from any other operator being present? I can add an ">" on the
RexNode in my own rule and then my SEARCH is no longer "simplified".
So I guess what I'm saying is that while I do support LooseRex and PlanningRex,
I think the worry on "only SEARCH should be in the planning phase" is
orthogonal. We should fix that problem for all RexNodes. Hampering
development for users of Calcite and causing users like me to be slowed down
isn't the right way to go, imo. There is currently no external support for a
commonly used operation.
> Restore use of IN operator in RexCall
> -------------------------------------
>
> Key: CALCITE-7232
> URL: https://issues.apache.org/jira/browse/CALCITE-7232
> Project: Calcite
> Issue Type: Task
> Reporter: Stamatis Zampetakis
> Priority: Major
>
> The use of {{IN}} operator in {{RexCall}} was superseded by the introduction
> of the {{SEARCH}} operator (CALCITE-4173) and its use is strictly forbidden
> through
> [assertions|https://github.com/apache/calcite/blob/6cbbf560b721cb88354c33751aa72b16a58ded23/core/src/main/java/org/apache/calcite/rex/RexCall.java#L94].
> The {{SEARCH}} operator is more general and powerful than {{IN}} so it's a
> perfect abstraction to use during the optimization phase.
> However, most databases don't have a {{SEARCH}} operator so the latter needs
> to be transformed back to {{IN}} (or something else) at some point in time.
> For instance, Apache Hive has two ways of generating an executable plan:
> * take a {{RelNode}} and generate an AST tree
> * take a {{RelNode}} and generate a Hive Operator tree
> both of which are eventually going to be executed.
> *If we don't allow* IN in a RexCall, then it means that we need to create
> special code to handle SEARCH in both code paths that differ only slightly in
> each case. (In reality the situation is more complicated for Hive because
> there are at least two more places where we need to do a SEARCH to IN
> transformation).
> *If we allow IN* in a RexCall, then at the end of the RelNode optimization
> phase we can "expand" {{SEARCH}} to {{IN}} so the transformation logic only
> appears in one place and it remains a {{RelNode}} to {{RelNode}} conversion.
> In fact, the same transformation logic could be exploited in
> [SqlImplementor|https://github.com/apache/calcite/blob/6cbbf560b721cb88354c33751aa72b16a58ded23/core/src/main/java/org/apache/calcite/rel/rel2sql/SqlImplementor.java#L815]
> that does another {{RelNode}} to "something" conversion.
> The obvious downside with this proposal is that if people start mixing the IN
> operator in various optimization rules/phases it can certainly affect the
> quality of the plans and the planning time.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
