Re: [DISCUSSION] Extension of Metadata Query

Thanks Julian for your detail reply, 1. I checked the Janino gened-code and the RelMetadataQuery/RelMetadataProvidor and almost can make sure MetadataQuery only use the RelMetadataProvidor#handlers method for multiple dispatch, the  RelMetadataProvidor#apply is only used for MetadataFactory.

Re: [DISCUSSION] Extension of Metadata Query

Thanks for raising this, Danny. Actually I have the same question too. > RelMetadataQuery is not an extension point. Its sole purpose is to to keep state (the cache and cycle-checking) I think users may extend the RelMetadataQuery if wanting to query more metadata, such as TopK values. Best,

Re: Correlate Join SemiJoin transformation

I think the complexity mostly comes from the value generator, which is the engineering foundation of current decorrelation. Best, Danny Chan 在 2019年6月5日 +0800 AM10:45，Chunwei Lei ，写道： > Thanks for raising this, Haisheng. > > Do you mean that we should have better subquery unnesting? > > > > >

Re: Giving the Calcite logo some love

I would prefer  https://github.com/zabetak/calcite/blob/calcite-logo/site/img/logo-alt2-v1.svg if the hammer can be smaller :) Best, Danny Chan 在 2019年6月5日 +0800 AM8:32，Albert ，写道： > I will vote "logo-alt1-v5.svg > "

Re: Correlate Join SemiJoin transformation

Thanks for raising this, Haisheng. Do you mean that we should have better subquery unnesting? Best, Chunwei On Tue, Jun 4, 2019 at 8:27 AM Haisheng Yuan wrote: > Hi, > > Since we have commited CALCITE-2969, and in the next release of 1.21, we > will deprecate EquiJoin and make enumerable

Re: Execute multiple RelNodes from single RelNode

Hi, Ivan. Could you please explain more detail for your question? Maybe give an example. Best, Chunwei On Tue, Jun 4, 2019 at 8:59 PM Ivan Grgurina wrote: > Can I create multiple top-level RelNodes out of the single SqlNode in > SqlToRelConverter class or single RelNode through RelOptRules

Re: [DISCUSS] Automated website builds

+1. Thanks for your work, Francis. Best, Chunwei On Wed, Jun 5, 2019 at 1:46 AM Josh Elser wrote: > +1 > > On 6/4/19 8:43 AM, Michael Mior wrote: > > I see no reason not to test this out. I'd say go for it! Thanks Francis > :) > > -- > > Michael Mior > > mm...@apache.org > > > > Le lun. 3

Re: Giving the Calcite logo some love

I will vote the one Daniel sent[1]. But I think t will be better if the first letter can be upper case, namely Calcite. [1] http://humbedooh.com/calcite-proposed.svg Best, Chunwei On Wed, Jun 5, 2019 at 8:32 AM Albert wrote: > I will vote "logo-alt1-v5.svg > < >

Re: Linq expressions to RexNode

Although requirement of such functionality is not usual but there is actually a method "org.apache.calcite.prepare.CalcitePrepareImpl.EmptyScalarTranslator.toRex(Expression expression)" which intended to do translation from linq4j expressions to rex nodes. But since the method is currently

Re: Giving the Calcite logo some love

I will vote "logo-alt1-v5.svg " , looks nice. On Wed, Jun 5, 2019 at 6:11 AM Stamatis Zampetakis wrote: > I created a branch to gather all alternative logos [1]. > > Among the two aforementioned proposals, I added a

[jira] [Created] (CALCITE-3111) Allow custom implementations of Correlate in RelDecorrelator

Juhwan Kim created CALCITE-3111: --- Summary: Allow custom implementations of Correlate in RelDecorrelator Key: CALCITE-3111 URL: https://issues.apache.org/jira/browse/CALCITE-3111 Project: Calcite

Re: [DISCUSSION] Extension of Metadata Query

Thanks for bringing this up Danny. I guess the discussion came up due to CALCITE-2885 [1]. Looking back into it, I am not sure that the intention there is to make the RelMetadataQuery pluggable. We could possibly solve the performance problem without extending the RelMetadataQuery. We have to

Re: Giving the Calcite logo some love

I created a branch to gather all alternative logos [1]. Among the two aforementioned proposals, I added a few more variants (check logo-alt* under the img directory). Have a look and let me know what you think. I'm open to any ideas and suggestions. [1]

Re: Linq expressions to RexNode

Hi Khai, I don't think there is such kind of utility function in Calcite. - Haisheng Yuan-- 发件人：Khai Tran 日　期：2019年06月05日 01:28:21 收件人：dev@calcite.apache.org (dev@calcite.apache.org) 主　题：Linq expressions to RexNode Just a bit

[jira] [Created] (CALCITE-3110) Enable parallel execution of parameterized test

Haisheng Yuan created CALCITE-3110: -- Summary: Enable parallel execution of parameterized test Key: CALCITE-3110 URL: https://issues.apache.org/jira/browse/CALCITE-3110 Project: Calcite

Re: Re: Re: Re: Re: Re: [DISCUSS] Parallel parameterized unit tests

Looks like we already used https://github.com/stephenc/jcip-annotations in pom.xml, I will keep pom.xml untouched. - Haisheng Yuan-- 发件人：Julian Hyde 日　期：2019年06月05日 02:39:43 收件人：dev@calcite.apache.org 主　题：Re: Re: Re: Re: Re:

Re: Re: Re: Re: Re: [DISCUSS] Parallel parameterized unit tests

Be sure to use a version of jcip-annotations that has an acceptable license. https://github.com/stephenc/jcip-annotations seems suitable; the original, https://search.maven.org/artifact/net.jcip/jcip-annotations/1.0/jar, does not. On Tue, Jun 4, 2019 at 11:36 AM Haisheng Yuan wrote: > > Yes, I

Re: Re: Re: Re: Re: [DISCUSS] Parallel parameterized unit tests

Yes, I will do it. - Haisheng Yuan-- 发件人：Julian Hyde 日　期：2019年06月05日 02:23:24 收件人：dev@calcite.apache.org 抄　送：Stamatis Zampetakis 主　题：Re: Re: Re: Re: [DISCUSS] Parallel parameterized unit tests I think we have quorum. Can someone

Re: Re: Re: Re: [DISCUSS] Parallel parameterized unit tests

I think we have quorum. Can someone please commit this? Do we need to log a JIRA case to remind us to remove this workaround in future? On Tue, Jun 4, 2019 at 11:10 AM Ruben Q L wrote: > > I also confirm: @net.jcip.annotations.NotThreadSafe works for me too. I > agree, this seems the cleanest

Re: Re: Re: Re: [DISCUSS] Parallel parameterized unit tests

I also confirm: @net.jcip.annotations.NotThreadSafe works for me too. I agree, this seems the cleanest solution. Le mar. 4 juin 2019 à 19:54, Haisheng Yuan a écrit : > I tried the annotaion @net.jcip.annotations.NotThreadSafe that Stamatis > suggested, it works for me. This might be the least

Re: Re: Re: Re: [DISCUSS] Parallel parameterized unit tests

I tried the annotaion @net.jcip.annotations.NotThreadSafe that Stamatis suggested, it works for me. This might be the least change for us with little impact. So what is the plan? Can we incorporate this change before 1.20 release? Currently I have to explicitly disable/annotate the

Re: [DISCUSSION] Extension of Metadata Query

> 1. Why we have 2 methods in RelMetadataProvider? The metadata system is complicated. We need to allow multiple handlers for any given call. So, making a metadata call involves multiple dispatch [1] based on the metadata method being called, the type of RelNode, and the handlers that are

Re: [DISCUSS] Automated website builds

+1 On 6/4/19 8:43 AM, Michael Mior wrote: I see no reason not to test this out. I'd say go for it! Thanks Francis :) -- Michael Mior mm...@apache.org Le lun. 3 juin 2019 à 21:04, Francis Chuang a écrit : A few months ago, I raised the possibility to automating our website builds, so that we

Re: Pluggable JDBC types

The only difference I need to achieve while handling both types, is the returned column type name (ResultSet.getMetaData().getColumnTypeName(int index)). The returned value is VARCHAR even if the column type is a user defined type with the alias TEXT. While getting the column type name using a

Linq expressions to RexNode

Just a bit strange, but just wonder if in calcite code base, is there any util function to convert linq expression back to RexNode?

Re: Giving the Calcite logo some love

I prefer both over the current logo. (And I made the current logo.) Let's keep the discussion going, and get to a new logo. On Tue, Jun 4, 2019 at 9:42 AM Ivan Grgurina wrote: > > I prefer the one Daniel sent. It looks cleaner, but maybe the "periodic > table" logo can be made better by

Re: Giving the Calcite logo some love

I prefer the one Daniel sent. It looks cleaner, but maybe the "periodic table" logo can be made better by simplifying it, the shadow on the letter C is... unusual. From: Stamatis Zampetakis Sent: Tuesday, June 4, 2019 6:32 PM To: dev@calcite.apache.org;

Re: Giving the Calcite logo some love

Thanks for digging this out Daniel! At this point we have two candidates: http://humbedooh.com/calcite-proposed.svg https://svgshare.com/s/86r Do we like any of above more than our current logo (the way they are or with slight modifications) ? On Mon, Jun 3, 2019 at 3:15 AM Yuzhao Chen

Re: Pluggable JDBC types

I am not sure what problem exactly we are trying to solve here (sorry for that). >From what I understood so far the requirement is to introduce a new built-in SQL type (i.e., TEXT). However, I am still trying to understand why do we need this. Are we going to treat TEXT and VARCHAR differently?

Re: Pluggable JDBC types

Thanks Lai, I beleive your analysis is correct. Which brings up another question: Is it ok if we add support for what I'm trying to do here ? I can gladly work on that but I need to know if it will be accepted. Thanks, Gelbana On Tue, Jun 4, 2019 at 8:38 AM Lai Zhou wrote: > @Muhammad

Execute multiple RelNodes from single RelNode

Can I create multiple top-level RelNodes out of the single SqlNode in SqlToRelConverter class or single RelNode through RelOptRules and have Calcite push it to the databases? Ivan Grgurina Research Assistant (ZEMRIS)

Re: [DISCUSS] Automated website builds

I see no reason not to test this out. I'd say go for it! Thanks Francis :) -- Michael Mior mm...@apache.org Le lun. 3 juin 2019 à 21:04, Francis Chuang a écrit : > > A few months ago, I raised the possibility to automating our website > builds, so that we will not need to manually build the site

[jira] [Created] (CALCITE-3109) RepeatUnion improvements

Ruben Quesada Lopez created CALCITE-3109: Summary: RepeatUnion improvements Key: CALCITE-3109 URL: https://issues.apache.org/jira/browse/CALCITE-3109 Project: Calcite Issue Type:

Re: Re: Extracting all columns used in a query

Hi Adam, I developed a solution to your problem (and mine  ) as part of my master thesis. Code is available at [1]. If you have any questions regarding the code, feel free to ask me. [1]

Re: Re: Extracting all columns used in a query

Hi Adam, Calcite defintely can do this. But can you first clarify what do you mean by all the columns in a query? e.g. R(r1, r2,r3), S(s1,s2,s3) SELECT r1+s1 FROM R,S WHERE r3=s3; What do you want to extract from this query? r1,r3 for R and s1, s3 for S? And why do you want do that? - Haisheng

Re: Extracting all columns used in a query

Hey Adam, I am not sure exactly what information you need, and at which level (SqlNode/RelNode), but maybe you can exploit what is present in RelRoot [1]. Follow the calls to the constructor to see which APIs can provide you what you need (check for instance, SqlToRelConverter.convertQuery [2]).

Re: Pluggable JDBC types

@Muhammad Gelbana，I think you just register an alias-name 'TEXT' for the SqlType 'VARCHAR'. The parser did the right thing here, see https://github.com/apache/calcite/blob/9721283bd0ce46a337f51a3691585cca8003e399/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L1566 When