Re: Sort getting removed during optimization

Hi Julian, Xiong, thanks for your fast replies! So first, the default Rules were registered: planner = new VolcanoPlanner(); RelOptUtil.registerDefaultRules(planner, false, true); And as traits I used: planner.addRelTraitDef(ConventionTraitDef.INSTANCE);

Re: [DISCUSS] Trolls and community

About maven, I still miss it. Arguing is pointless If all you have is a hammer, everything looks like a nail Regards! Aron Tao Vladimir Sitnikov 于2021年12月23日周四 07:10写道： > >[2] > http://ceki.blogspot.com/2010/05/forces-and-vulnerabilites-of-apache.html > > ^^ It is a must-read indeed. > I

Build failed in Jenkins: Calcite » Calcite-snapshots #47

See Changes: [nobigogle] [CALCITE-4977] Support Snapshot in RelMdColumnOrigins -- [...truncated 355.33 KB...] 2022-01-11 06:44:26,817 [s6-admin-0] WARN

Re: Different behavior bewteen '>' and '='

Yes, this is by design.I believe that the SQL standard set the rules. It’s not that surprising that ‘=‘ has different behavior than ordering-based comparisons such as ‘>’. Consider: given a DATE value d, and a TIMESTAMP value t, it is reasonable to ask ‘is t > d?’ but less reasonable to ask

[jira] [Created] (CALCITE-4982) NoNull filed is pushed down into right of full-join in 'ProjectJoinTransposeRule'

Xurenhe created CALCITE-4982: Summary: NoNull filed is pushed down into right of full-join in 'ProjectJoinTransposeRule' Key: CALCITE-4982 URL: https://issues.apache.org/jira/browse/CALCITE-4982 Project:

Different behavior bewteen '>' and '='

Hi community, I recently ran into a problem that when we disable type coercion by SqlValidator#setEnableTypeCoercion(false), there will be two different behaviors between '>' and '=': 1. '>' between character and numeric (e.g. '1' > 1), the character will be implicitly converted to numeric 2.

[jira] [Created] (CALCITE-4981) tpch q21 query plan has many cartesian joins after decorrelation

Yifei Yang created CALCITE-4981: --- Summary: tpch q21 query plan has many cartesian joins after decorrelation Key: CALCITE-4981 URL: https://issues.apache.org/jira/browse/CALCITE-4981 Project: Calcite

Re: Sort getting removed during optimization

Is it possible that the Sort is being removed because some component knows that the input is already sorted? In particular, if a relation has at most one row, it is always sorted. Maybe the planner is deducing this via a some row-count metadata or uniqueness constraint. > On Jan 10, 2022, at

Re: Sort getting removed during optimization

If I understand correctly, If we remove the BINDABLE_SORT_RULE, the result will throw an exception about the Plan transformation. So it looks like a wrong rule's result. If you don't customize the rule, It is a bug, and please test this using Calcite's new version.

Re: Calcite-Clojure integration - use Clojure to implement calcite back-ends

Hi Eugen, Thanks for sharing this project. It will be very helpful for those who want to use Calcite with Clojure. I guess many people will be interested to learn more about the project and see it in action. If you plan to give a talk to the Calcite meetup on January 17, please send me a title,

Sort getting removed during optimization

Hi all, I just observed a Plan transformation that I don’t quite understand. The Logical Plan is: LogicalSort(sort0=[$0], dir0=[DESC]) LogicalProject(time=[COALESCE($0, $2)], s1=[$1], s0=[$3]) LogicalJoin(condition=[=($0, $2)], joinType=[full]) LogicalTableScan(table=[[root,

Build failed in Jenkins: Calcite » Calcite-snapshots #46

See Changes: [alessandro.solimando] Site: Add Alessandro Solimando as committer -- [...truncated 320.68 KB...] docker[redis:2.8.19] 2022-01-10

[jira] [Created] (CALCITE-4980) Babel parser support MySQL equal operator '<=>'

Xurenhe created CALCITE-4980: Summary: Babel parser support MySQL equal operator '<=>' Key: CALCITE-4980 URL: https://issues.apache.org/jira/browse/CALCITE-4980 Project: Calcite Issue Type: New