[jira] [Created] (CALCITE-4111) Remove VolcanoPlannerPhase in VolcanoPlanner

Jiatao Tao created CALCITE-4111: --- Summary: Remove VolcanoPlannerPhase in VolcanoPlanner Key: CALCITE-4111 URL: https://issues.apache.org/jira/browse/CALCITE-4111 Project: Calcite Issue Type:

Re: [DISCUSS] Make RexNode serializable

Serialize the RexNode as Json format is a solution but I’m afraid it can not solve the problem completely. One problem with it is how to re-parse the json format back to RexNode, the current RelJsonReader can only re-parse the RelNode but not RexNode, and it needs the RelOptSchema to lookup the

Re: Correlated subquery losing aggregator operator in inner join?

Since this discussion is moved to email thread, I just copy something I found and replied in that JIRA for the reference: SqlToRelConverter ends with creating a RexSubQuery for that subquery, and leaves it to JOIN condition. The string representation of RexSubQuery seems just $7. If you check

Re: [DISCUSS] Make RexNode serializable

Hi Rui, AFAIK, RelNodes can be serialized to and deserialized from JSON format. See test [1] as an example. If I understand it correct, RelNodes are serialized along with enclosed RexNodes, so you can transfer them over the network as plain strings. [1]

Re: [DISCUSS] Make RexNode serializable

Rui Il Mar 7 Lug 2020, 20:30 Rui Wang ha scritto: > Hi Community, > > In Apache Beam we are facing a use case where we need to keep RexNode in > our distributed primitives. Because of the nature of distributed computing, > Beam requires the usage of those primitives be serializable (thus those

Correlated subquery losing aggregator operator in inner join?

Hi, I am following up on JIRA-4100. I am trying to understand the plan generated by the SQL query select e.empno, e.sal, e.deptno emp_dept, d.deptno dep_dept from emp e left join dept d on e.deptno = ( select max(sal) from emp where deptno = e.deptno) The plan

[DISCUSS] Make RexNode serializable

Hi Community, In Apache Beam we are facing a use case where we need to keep RexNode in our distributed primitives. Because of the nature of distributed computing, Beam requires the usage of those primitives be serializable (thus those primitives can be sent over the network to backend/workers for

Re: Doubts about VolcanoPlannerPhase

Sorry, I think I was wrong, maybe I over complicated things. I don't mind removing it, which seems pretty useless. On 2020/07/07 07:03:20, Roman Kondakov wrote: > Hi Aron, > > there was a small discussion about this several months ago [1]. > > [1]

Re: Doubts about VolcanoPlannerPhase

Hi Roman Thanks for you information, in this case, my opinion is to delete the related logical in Volcano planner, but keep the VolcanoPlannerPhase mechanism for future use. Regards! Aron Tao Roman Kondakov 于2020年7月7日周二 下午3:03写道： > Hi Aron, > > there was a small discussion about this

[jira] [Created] (CALCITE-4110) Provide more info when log rule pop

Jiatao Tao created CALCITE-4110: --- Summary: Provide more info when log rule pop Key: CALCITE-4110 URL: https://issues.apache.org/jira/browse/CALCITE-4110 Project: Calcite Issue Type:

Re: Doubts about VolcanoPlannerPhase

Hi Aron, there was a small discussion about this several months ago [1]. [1] https://github.com/apache/calcite/pull/1840#discussion_r387967624 -- Roman Kondakov On 07.07.2020 09:52, JiaTao Tao wrote: Seems only use OPTIMIZE phase, can we remove this mechanism? Regards! Aron Tao

Doubts about VolcanoPlannerPhase

Seems only use OPTIMIZE phase, can we remove this mechanism? Regards! Aron Tao

[jira] [Created] (CALCITE-4109) Introduce the maxIterations for volcano planner

Jiatao Tao created CALCITE-4109: --- Summary: Introduce the maxIterations for volcano planner Key: CALCITE-4109 URL: https://issues.apache.org/jira/browse/CALCITE-4109 Project: Calcite Issue