Re: [ANNOUNCE] Apache Calcite 1.23.0 released
Great Enrico Il Gio 28 Mag 2020, 05:12 Chunwei Lei ha scritto: > Nice job, Haisheng! > > > Best, > Chunwei > > > On Thu, May 28, 2020 at 10:42 AM XING JIN wrote: > > > Thanks a lot for driving this, Haisheng! > > > > Best, > > Jin > > > > Stamatis Zampetakis 于2020年5月28日周四 上午7:14写道： > > > > > Many thanks again Haisheng, the release has your signature on it and it > > is > > > in many places :) > > > > > > On Wed, May 27, 2020 at 9:34 PM Haisheng Yuan > wrote: > > > > > > > The Apache Calcite team is pleased to announce the release of Apache > > > > Calcite 1.23.0. > > > > > > > > Calcite is a dynamic data management framework. Its cost-based > > > > optimizer converts queries, represented in relational algebra, into > > > > executable plans. Calcite supports many front-end languages and > > > > back-end data engines, and includes an SQL parser and, as a > > > > sub-project, the Avatica JDBC driver. > > > > > > > > This release comes two months after 1.22.0. It includes more than > > > > 100 resolved issues, comprising of a few new features as well as > > > > general improvements and bug-fixes. It includes support for top > > > > down trait request and trait enforcement without abstract converter, > > > > ClickHouse dialect, SESSION and HOP Table functions, and many > > > > more bug fixes and improvements. > > > > > > > > You can start using it in Maven by simply updating your dependency > to: > > > > > > > > > > > > org.apache.calcite > > > > calcite-core > > > > 1.23.0 > > > > > > > > > > > > If you'd like to download the source release, you can find it here: > > > > > > > > https://calcite.apache.org/downloads/ > > > > > > > > You can read more about the release (including release notes) here: > > > > > > > > https://calcite.apache.org/news/2020/05/23/release-1.23.0/ > > > > > > > > We welcome your help and feedback. For more information on how to > > > > report problems, and to get involved, visit the project website at: > > > > > > > > https://calcite.apache.org/ > > > > > > > > Thanks to everyone involved! > > > > > > > > > >
Re: [ANNOUNCE] Apache Calcite 1.23.0 released
Nice job, Haisheng! Best, Chunwei On Thu, May 28, 2020 at 10:42 AM XING JIN wrote: > Thanks a lot for driving this, Haisheng! > > Best, > Jin > > Stamatis Zampetakis 于2020年5月28日周四 上午7:14写道： > > > Many thanks again Haisheng, the release has your signature on it and it > is > > in many places :) > > > > On Wed, May 27, 2020 at 9:34 PM Haisheng Yuan wrote: > > > > > The Apache Calcite team is pleased to announce the release of Apache > > > Calcite 1.23.0. > > > > > > Calcite is a dynamic data management framework. Its cost-based > > > optimizer converts queries, represented in relational algebra, into > > > executable plans. Calcite supports many front-end languages and > > > back-end data engines, and includes an SQL parser and, as a > > > sub-project, the Avatica JDBC driver. > > > > > > This release comes two months after 1.22.0. It includes more than > > > 100 resolved issues, comprising of a few new features as well as > > > general improvements and bug-fixes. It includes support for top > > > down trait request and trait enforcement without abstract converter, > > > ClickHouse dialect, SESSION and HOP Table functions, and many > > > more bug fixes and improvements. > > > > > > You can start using it in Maven by simply updating your dependency to: > > > > > > > > > org.apache.calcite > > > calcite-core > > > 1.23.0 > > > > > > > > > If you'd like to download the source release, you can find it here: > > > > > > https://calcite.apache.org/downloads/ > > > > > > You can read more about the release (including release notes) here: > > > > > > https://calcite.apache.org/news/2020/05/23/release-1.23.0/ > > > > > > We welcome your help and feedback. For more information on how to > > > report problems, and to get involved, visit the project website at: > > > > > > https://calcite.apache.org/ > > > > > > Thanks to everyone involved! > > > > > >
Re: [ANNOUNCE] Apache Calcite 1.23.0 released
Thanks a lot for driving this, Haisheng! Best, Jin Stamatis Zampetakis 于2020年5月28日周四 上午7:14写道： > Many thanks again Haisheng, the release has your signature on it and it is > in many places :) > > On Wed, May 27, 2020 at 9:34 PM Haisheng Yuan wrote: > > > The Apache Calcite team is pleased to announce the release of Apache > > Calcite 1.23.0. > > > > Calcite is a dynamic data management framework. Its cost-based > > optimizer converts queries, represented in relational algebra, into > > executable plans. Calcite supports many front-end languages and > > back-end data engines, and includes an SQL parser and, as a > > sub-project, the Avatica JDBC driver. > > > > This release comes two months after 1.22.0. It includes more than > > 100 resolved issues, comprising of a few new features as well as > > general improvements and bug-fixes. It includes support for top > > down trait request and trait enforcement without abstract converter, > > ClickHouse dialect, SESSION and HOP Table functions, and many > > more bug fixes and improvements. > > > > You can start using it in Maven by simply updating your dependency to: > > > > > > org.apache.calcite > > calcite-core > > 1.23.0 > > > > > > If you'd like to download the source release, you can find it here: > > > > https://calcite.apache.org/downloads/ > > > > You can read more about the release (including release notes) here: > > > > https://calcite.apache.org/news/2020/05/23/release-1.23.0/ > > > > We welcome your help and feedback. For more information on how to > > report problems, and to get involved, visit the project website at: > > > > https://calcite.apache.org/ > > > > Thanks to everyone involved! > > >
[jira] [Created] (CALCITE-4028) Unknown error in simple query from JDBCSchema connection to MS SqlServer
David Hait created CALCITE-4028:
---
Summary: Unknown error in simple query from JDBCSchema connection
to MS SqlServer
Key: CALCITE-4028
URL: https://issues.apache.org/jira/browse/CALCITE-4028
Project: Calcite
Issue Type: Bug
Components: jdbc-adapter
Affects Versions: 1.23.0
Reporter: David Hait
I tried to replicate the "Background" example, but with MSSQL instead of MySql.
This is failing and it is not obvious why - the exception and message do not
give enough information.
{{BasicDataSource dataSource = new BasicDataSource();}}
{{dataSource.setUrl("jdbc:sqlserver://tsql202.dc.optionmetrics.com");}}
{{dataSource.setUsername("sa");}}
{{dataSource.setPassword("singular1");}}
{{dataSource.setDefaultCatalog("ivydb");}}
{{dataSource.setDefaultSchema("dbo");}}
{{Schema schema = JdbcSchema.create(rootSchema,"sql",dataSource,null,null);}}
{{rootSchema.add("dbo",schema);}}
{{Statement statement = calciteConnection.createStatement();}}
{{var rs2 = statement.executeQuery("SELECT SecurityID from dbo.SECURITY");}}
{{System.out.println(rs2);}}
{{This gave an undecipherable exception:}}
java.sql.SQLException: Error while executing SQL "SELECT SecurityID from
dbo.SECURITY": nulljava.sql.SQLException: Error while executing SQL "SELECT
SecurityID from dbo.SECURITY": null
at org.apache.calcite.avatica.Helper.createException(Helper.java:56) at
org.apache.calcite.avatica.Helper.createException(Helper.java:41) at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
at
org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
at
com.optionmetrics.adamo.AdamoApplicationTests.calciteDriverTest(AdamoApplicationTests.java:41)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:686)
at
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
at
org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:104)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:212)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:208)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:137)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:71)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:135)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$7(NodeTestTask.java:125)
at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:135)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:123)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
Re: [ANNOUNCE] Apache Calcite 1.23.0 released
Many thanks again Haisheng, the release has your signature on it and it is in many places :) On Wed, May 27, 2020 at 9:34 PM Haisheng Yuan wrote: > The Apache Calcite team is pleased to announce the release of Apache > Calcite 1.23.0. > > Calcite is a dynamic data management framework. Its cost-based > optimizer converts queries, represented in relational algebra, into > executable plans. Calcite supports many front-end languages and > back-end data engines, and includes an SQL parser and, as a > sub-project, the Avatica JDBC driver. > > This release comes two months after 1.22.0. It includes more than > 100 resolved issues, comprising of a few new features as well as > general improvements and bug-fixes. It includes support for top > down trait request and trait enforcement without abstract converter, > ClickHouse dialect, SESSION and HOP Table functions, and many > more bug fixes and improvements. > > You can start using it in Maven by simply updating your dependency to: > > > org.apache.calcite > calcite-core > 1.23.0 > > > If you'd like to download the source release, you can find it here: > > https://calcite.apache.org/downloads/ > > You can read more about the release (including release notes) here: > > https://calcite.apache.org/news/2020/05/23/release-1.23.0/ > > We welcome your help and feedback. For more information on how to > report problems, and to get involved, visit the project website at: > > https://calcite.apache.org/ > > Thanks to everyone involved! >
Re: [DISCUSS] What should ProjectFilterTransposeRule do?
Hello, I looked into the rule recently but to be honest I already forgot what it really does. Expect: B Hope: A Comments: Judging by the name I would expect B, pushing as much as possible from the top project but not altering the filter. In the end it is just a transpose. On the other hand, I would use the rule mostly as an alternative to RelFieldTrimmer (along with other rules) in order to prune out unnecessary columns as early as possible. Thus, I think option A is what I would like. If it works like B then in some cases it could have also the opposite effect of what I would like; fattening the tuples instead of slimming them down. SELECT sal, comm, sal + comm AS remuneration, sal * 0.45 AS incometax, sal * 0.03 AS surchargetax FROM Emp WHERE deptno = 10 SELECT sal, comm, renumeration, incometax, surchargetax FROM ( SELECT sal, comm, sal + comm AS remuneration, sal * 0.45 As incometax, sal * 0.03 AS surchargetax, deptno FROM Emp) WHERE deptno = 10 Best, Stamatis PS. I will go now and check what the rule does :) On Wed, May 27, 2020 at 8:45 PM Julian Hyde wrote: > As part of https://issues.apache.org/jira/browse/CALCITE-3975, I've > been looking into what ProjectFilterTransposeRule does with > expressions. It's one of our oldest rules, and I thought I knew what > it did. But the rule does not do what I expect. I've like to conduct a > straw poll to see what other people think. > > Consider the following query (a Project on top of a Filter on a Scan). > > SELECT sal + comm AS remuneration > FROM Emp > WHERE deptno = 10 > > After applying ProjectFilterTransposeRule, what result would you > expect? What would the ideal result be? Are there any extreme cases > (large project lists, complex expressions, expensive filter > expressions) where the rule should do something different? > > Please fill out the following: > > Expect: > Hope: > Comments: > > Option A. Push down references to the fields needed by filter and > project expressions > > SELECT sal + comm AS remuneration > FROM ( > SELECT sal, comm, deptno > FROM Emp) > WHERE deptno = 10 > > B. Push down the project expression, and references to the fields > needed by the filter > > SELECT remuneration > FROM ( > SELECT sal + comm AS remuneration, deptno > FROM Emp) > WHERE deptno = 10 > > C. Push down the project and filter expressions > > SELECT remuneration > FROM ( > SELECT sal + comm AS remuneration, deptno = 10 AS predicate > FROM Emp) > WHERE predicate > > Julian >
Re: [DISCUSS] Towards Calcite-Avatica 1.17.0
Now that Calcite 1.23.0 has been released I think it's a good time to try to get Avatica 1.17.0 released. There are currently 10 open PRs on Github [1]. Can community members please review and comment on them if there are some spare cycles available? If we can get some of those PRs merged, it would be really great and they can go into the 1.17.0 release. Francis [1] https://github.com/apache/calcite-avatica/pulls On 5/05/2020 9:00 am, Francis Chuang wrote: There hasn't been any commits to the repository since I last sent the message. Let's focus on Calcite 1.23.0 and revisit Avatica after the Calcite release. Francis On 20/04/2020 8:32 am, Francis Chuang wrote: Hey everyone, I am planning to make rc0 available for voting towards the end of April / start of May. How does this look in terms of timing? Francis On 12/04/2020 2:51 am, Stamatis Zampetakis wrote: Thanks again for taking the lead on this Francis! Personally, I am quite busy these days but will do my best to check 1-2 PRs. On Fri, Apr 10, 2020 at 2:57 PM Josh Elser wrote: Always a good idea. I'll add this to my list and see if I can help get any committed. It's been a while since I've looked at the list. On 4/8/20 7:59 PM, Francis Chuang wrote: The last avatica release was in December last year. From activity on our mailing lists and the Calcite repository, it feels like there's currently a lull and things aren't as active. Would this be a good opportunity to work on Avatica and push a release out? There are currently 10 open PRs for Avatica [1] and I think if they are reviewed and merged, it wold be possible to close a huge chunk of them. I am happy to be RM for this release, but will need help from the community to review and merge those PRs. Francis [1] https://github.com/apache/calcite-avatica/pulls
Re: Master is open
Yes, master branch is ready to accept new commits. On 2020/05/27 19:26:01, Julian Hyde wrote: > Thanks for committing those PRs. I think we should re-open master now. > > On Sun, May 24, 2020 at 4:34 PM Haisheng Yuan wrote: > > > > I have gone over those deferred PRs that were good to go and committed them. > > Nothing blocker from my side. > > > > Haisheng > > > > On 2020/05/24 20:03:00, Haisheng Yuan wrote: > > > OK, let's keep master closed for now. I can confirm that those PRs tagged > > > with LGTM are ready to merge. I can go ahead and merge them, but for > > > others we need other reviewers to help confirm. > > > > > > On 2020/05/24 19:53:09, Julian Hyde wrote: > > > > Yes, review and (if they are ready) commit them before opening master. > > > > > > > > On Sun, May 24, 2020 at 11:30 AM Haisheng Yuan wrote: > > > > > > > > > > I went over the JIRAs, I marked those fix-for-1.23.0 (but didn't get > > > > > chance to get into 1.23.0) to 1.24.0. > > > > > By handling those deferred PRs, do you mean we first review and > > > > > commit these PRs? > > > > > > > > > > Thanks, > > > > > Haisheng > > > > > > > > > > On 2020/05/24 18:22:59, Julian Hyde wrote: > > > > > > What about the plan to keep it closed until we handled those > > > > > > deferred PRs? > > > > > > > > > > > > Julian > > > > > > > > > > > > > On May 24, 2020, at 08:19, Haisheng Yuan wrote: > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > Calcite master branch is open for commit now. > > > > > > > > > > > > > > Cheers, > > > > > > > Haisheng > > > > > > > > > > > > > >
[ANNOUNCE] Apache Calcite 1.23.0 released
The Apache Calcite team is pleased to announce the release of Apache Calcite 1.23.0. Calcite is a dynamic data management framework. Its cost-based optimizer converts queries, represented in relational algebra, into executable plans. Calcite supports many front-end languages and back-end data engines, and includes an SQL parser and, as a sub-project, the Avatica JDBC driver. This release comes two months after 1.22.0. It includes more than 100 resolved issues, comprising of a few new features as well as general improvements and bug-fixes. It includes support for top down trait request and trait enforcement without abstract converter, ClickHouse dialect, SESSION and HOP Table functions, and many more bug fixes and improvements. You can start using it in Maven by simply updating your dependency to: org.apache.calcite calcite-core 1.23.0 If you'd like to download the source release, you can find it here: https://calcite.apache.org/downloads/ You can read more about the release (including release notes) here: https://calcite.apache.org/news/2020/05/23/release-1.23.0/ We welcome your help and feedback. For more information on how to report problems, and to get involved, visit the project website at: https://calcite.apache.org/ Thanks to everyone involved!
Re: Master is open
Thanks for committing those PRs. I think we should re-open master now. On Sun, May 24, 2020 at 4:34 PM Haisheng Yuan wrote: > > I have gone over those deferred PRs that were good to go and committed them. > Nothing blocker from my side. > > Haisheng > > On 2020/05/24 20:03:00, Haisheng Yuan wrote: > > OK, let's keep master closed for now. I can confirm that those PRs tagged > > with LGTM are ready to merge. I can go ahead and merge them, but for others > > we need other reviewers to help confirm. > > > > On 2020/05/24 19:53:09, Julian Hyde wrote: > > > Yes, review and (if they are ready) commit them before opening master. > > > > > > On Sun, May 24, 2020 at 11:30 AM Haisheng Yuan wrote: > > > > > > > > I went over the JIRAs, I marked those fix-for-1.23.0 (but didn't get > > > > chance to get into 1.23.0) to 1.24.0. > > > > By handling those deferred PRs, do you mean we first review and commit > > > > these PRs? > > > > > > > > Thanks, > > > > Haisheng > > > > > > > > On 2020/05/24 18:22:59, Julian Hyde wrote: > > > > > What about the plan to keep it closed until we handled those deferred > > > > > PRs? > > > > > > > > > > Julian > > > > > > > > > > > On May 24, 2020, at 08:19, Haisheng Yuan wrote: > > > > > > > > > > > > Hi all, > > > > > > > > > > > > Calcite master branch is open for commit now. > > > > > > > > > > > > Cheers, > > > > > > Haisheng > > > > > > > > > >
[jira] [Created] (CALCITE-4027) Add -Doverwrite option to SqlToRelTestBase
Haisheng Yuan created CALCITE-4027: -- Summary: Add -Doverwrite option to SqlToRelTestBase Key: CALCITE-4027 URL: https://issues.apache.org/jira/browse/CALCITE-4027 Project: Calcite Issue Type: Improvement Components: core Reporter: Haisheng Yuan So that by setting overwrite=true, the expected xml file will be overwritten by actual output file automatically. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [VOTE] Release apache-calcite-1.23.0 (release candidate 1)
Haisheng, Thanks for the release announcement yesterday: https://lists.apache.org/thread.html/r555d7f90568ef199c65dfddcf58b14076ac803c0dca64d945d75ba69%40%3Cannounce.apache.org%3E. Can you also send it to dev@? Thank you for getting those 6 PRs into master (3985, 3988, 3910, 3999, 3478, 3950). Do you think we should re-open master for commits? Lastly, thank you for being release manager. Great job. This was a very smooth release. Julian On Wed, May 27, 2020 at 12:10 PM Haisheng Yuan wrote: > > Now it is back to normal: > > https://repo1.maven.org/maven2/org/apache/calcite/calcite-core/1.23.0/ > > On 2020/05/26 14:00:50, Haisheng Yuan wrote: > > Hi Enrico, > > > > Thanks for reporting the issue. > > > > I have created a JIRA ticket: > > https://issues.apache.org/jira/browse/INFRA-20326 > > > > Thanks, > > Haisheng > > > > On 2020/05/26 09:20:14, Enrico Olivelli wrote: > > > Vladimir o Haisheng > > > could you please open a ticket to INFRA ? > > > I can do it myself, with your permission (I am not in Calcite > > > PMC/committers group) > > > > > > Otherwise it is not possible to use Calcite 1.23.0 from downstream > > > projects > > > > > > Enrico > > > > > > Il giorno mar 26 mag 2020 alle ore 10:34 Vladimir Sitnikov < > > > sitnikov.vladi...@gmail.com> ha scritto: > > > > > > > ASF releases are shared with repository.apache.org: > > > > > > > > https://repository.apache.org/service/local/repositories/releases/content/org/apache/calcite/calcite-core/1.23.0/calcite-core-1.23.0.pom > > > > > > > > It might be there are issues with ASF Nexus and Sonatype Nexus sync. > > > > > > > > Vladimir > > > > > > > > >
Re: [VOTE] Release apache-calcite-1.23.0 (release candidate 1)
Now it is back to normal: https://repo1.maven.org/maven2/org/apache/calcite/calcite-core/1.23.0/ On 2020/05/26 14:00:50, Haisheng Yuan wrote: > Hi Enrico, > > Thanks for reporting the issue. > > I have created a JIRA ticket: > https://issues.apache.org/jira/browse/INFRA-20326 > > Thanks, > Haisheng > > On 2020/05/26 09:20:14, Enrico Olivelli wrote: > > Vladimir o Haisheng > > could you please open a ticket to INFRA ? > > I can do it myself, with your permission (I am not in Calcite > > PMC/committers group) > > > > Otherwise it is not possible to use Calcite 1.23.0 from downstream projects > > > > Enrico > > > > Il giorno mar 26 mag 2020 alle ore 10:34 Vladimir Sitnikov < > > sitnikov.vladi...@gmail.com> ha scritto: > > > > > ASF releases are shared with repository.apache.org: > > > > > > https://repository.apache.org/service/local/repositories/releases/content/org/apache/calcite/calcite-core/1.23.0/calcite-core-1.23.0.pom > > > > > > It might be there are issues with ASF Nexus and Sonatype Nexus sync. > > > > > > Vladimir > > > > > >
[DISCUSS] What should ProjectFilterTransposeRule do?
As part of https://issues.apache.org/jira/browse/CALCITE-3975, I've been looking into what ProjectFilterTransposeRule does with expressions. It's one of our oldest rules, and I thought I knew what it did. But the rule does not do what I expect. I've like to conduct a straw poll to see what other people think. Consider the following query (a Project on top of a Filter on a Scan). SELECT sal + comm AS remuneration FROM Emp WHERE deptno = 10 After applying ProjectFilterTransposeRule, what result would you expect? What would the ideal result be? Are there any extreme cases (large project lists, complex expressions, expensive filter expressions) where the rule should do something different? Please fill out the following: Expect: Hope: Comments: Option A. Push down references to the fields needed by filter and project expressions SELECT sal + comm AS remuneration FROM ( SELECT sal, comm, deptno FROM Emp) WHERE deptno = 10 B. Push down the project expression, and references to the fields needed by the filter SELECT remuneration FROM ( SELECT sal + comm AS remuneration, deptno FROM Emp) WHERE deptno = 10 C. Push down the project and filter expressions SELECT remuneration FROM ( SELECT sal + comm AS remuneration, deptno = 10 AS predicate FROM Emp) WHERE predicate Julian
Re: Link4j AST Node | ExpressionWriter Runtime Exception
Do you really need to create a new kind of Linq4j node? On Wed, May 27, 2020 at 11:03 AM Ravi Kapoor wrote: > > Hi Team, > > The Java AST Node interface in the calcite - linq4j project has below API > for converting expressions to java code > > *void accept(ExpressionWriter expressionWriter)* > > However, ExpressionWriter class is declared as package protected and not > part of exported API. > Could not understand the rationale behind this as the tree itself is public > > I need to create custom Node by extending a Statement or Expression from > Linq4j and override the accept of writer in order to covert my own Node > expression. > > In this case it goes to the parent accept() method which is of AbstractNode > and throws RuntimeException - unparse not supported. > > Can you please check on this? > > -- > Thanks, > Ravi Kapoor > +91-9818764564 > kapoorrav...@gmail.com
Link4j AST Node | ExpressionWriter Runtime Exception
Hi Team, The Java AST Node interface in the calcite - linq4j project has below API for converting expressions to java code *void accept(ExpressionWriter expressionWriter)* However, ExpressionWriter class is declared as package protected and not part of exported API. Could not understand the rationale behind this as the tree itself is public I need to create custom Node by extending a Statement or Expression from Linq4j and override the accept of writer in order to covert my own Node expression. In this case it goes to the parent accept() method which is of AbstractNode and throws RuntimeException - unparse not supported. Can you please check on this? -- Thanks, Ravi Kapoor +91-9818764564 kapoorrav...@gmail.com
Re: [DISCUSS] Why ProjectRemoveRule dose not consider field name when apply this rule
Sorry, I meant "I am not sure if Calcite does it" (likely not).
-Rui
On Wed, May 27, 2020 at 10:31 AM Rui Wang wrote:
> Hello,
>
> This topic was discussed in
> https://issues.apache.org/jira/browse/CALCITE-1584.
>
> I am sure if Calcite does it, but in another SQL parser/analyzer
> implementation I have saw, each logical plan has a top attribute about
> final output column names, so even nodes might be merged/removed, at least
> there are still output column names that we can get.
>
> -Rui
>
> On Wed, May 27, 2020 at 5:38 AM 董 一峰 wrote:
>
>> Hello everyone,
>>
>> When we run the following test case:
>> SQL:
>> WITH T_CTE (i1_cte, i2_cte) AS (
>>SELECT
>>i1,
>>d3
>>FROM
>>t1
>> )
>> SELECT
>>*
>> FROM
>>t2
>>JOIN T_CTE ON (t2.i1 = T_CTE.i1_cte)
>>
>>
>> Logical Plan(After ProjectRemoveRule):
>> LogicalJoin(condition=[=($0, $14)], joinType=[inner])
>> :- LogicalTableScan(table=[[default, db1, t2]])
>>+- LogicalCalc(expr#0..13=[{inputs}], i1=[$t0], d3=[$t2])
>>+- LogicalTableScan(table=[[default, db1, t1]])
>>
>>
>> We wish the output column name contain i1_cte, i2_cte, but calcite just
>> drop it.
>> After analysisinp the calcite code, we found the rule named
>> ProjectRemoveRule, it will remove the project if project and its input has
>> same size and type, but it confused me, why this rule dose not consider the
>> field name when remove project?
>>
>> Best Regards
>> Axis
>>
>>
Re: [DISCUSS] Why ProjectRemoveRule dose not consider field name when apply this rule
Hello,
This topic was discussed in
https://issues.apache.org/jira/browse/CALCITE-1584.
I am sure if Calcite does it, but in another SQL parser/analyzer
implementation I have saw, each logical plan has a top attribute about
final output column names, so even nodes might be merged/removed, at least
there are still output column names that we can get.
-Rui
On Wed, May 27, 2020 at 5:38 AM 董 一峰 wrote:
> Hello everyone,
>
> When we run the following test case:
> SQL:
> WITH T_CTE (i1_cte, i2_cte) AS (
>SELECT
>i1,
>d3
>FROM
>t1
> )
> SELECT
>*
> FROM
>t2
>JOIN T_CTE ON (t2.i1 = T_CTE.i1_cte)
>
>
> Logical Plan(After ProjectRemoveRule):
> LogicalJoin(condition=[=($0, $14)], joinType=[inner])
> :- LogicalTableScan(table=[[default, db1, t2]])
>+- LogicalCalc(expr#0..13=[{inputs}], i1=[$t0], d3=[$t2])
>+- LogicalTableScan(table=[[default, db1, t1]])
>
>
> We wish the output column name contain i1_cte, i2_cte, but calcite just
> drop it.
> After analysisinp the calcite code, we found the rule named
> ProjectRemoveRule, it will remove the project if project and its input has
> same size and type, but it confused me, why this rule dose not consider the
> field name when remove project?
>
> Best Regards
> Axis
>
>
[DISCUSS] Why ProjectRemoveRule dose not consider field name when apply this rule
Hello everyone,
When we run the following test case:
SQL:
WITH T_CTE (i1_cte, i2_cte) AS (
SELECT
i1,
d3
FROM
t1
)
SELECT
*
FROM
t2
JOIN T_CTE ON (t2.i1 = T_CTE.i1_cte)
Logical Plan(After ProjectRemoveRule):
LogicalJoin(condition=[=($0, $14)], joinType=[inner])
:- LogicalTableScan(table=[[default, db1, t2]])
+- LogicalCalc(expr#0..13=[{inputs}], i1=[$t0], d3=[$t2])
+- LogicalTableScan(table=[[default, db1, t1]])
We wish the output column name contain i1_cte, i2_cte, but calcite just drop it.
After analysisinp the calcite code, we found the rule named ProjectRemoveRule,
it will remove the project if project and its input has same size and type, but
it confused me, why this rule dose not consider the field name when remove
project?
Best Regards
Axis
