[jira] [Created] (CALCITE-3962) Make JSON_VALUE operands varadic

[Danny Chen (Jira)]

Danny Chen created CALCITE-3962:
---

 Summary: Make JSON_VALUE operands varadic
 Key: CALCITE-3962
 URL: https://issues.apache.org/jira/browse/CALCITE-3962
 Project: Calcite
  Issue Type: Sub-task
  Components: core
Affects Versions: 1.22.0, 1.21.0
Reporter: Danny Chen
Assignee: Danny Chen
 Fix For: 1.23.0






--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [DISCUSS] Towards Cascades Optimizer

[Jinpeng Wu]

Hi, Roman. It's great to see your proposal. Actually my team has also been
working on a cascade planner based on calcite.  And we already have some
outcome as well.  Maybe we can combine our works.

I've pushed my code as https://github.com/apache/calcite/pull/1950 .

Our works have many places in common. We both developed a new
CascadePlanner and avoid modifying the old VolcanoPlanner directly. We
both implemented the top-down search strategy according to the
Columnbia optimizer
generator
。But
we also have some differences.

The first difference is that I try to reuse the existing VolcanoPlanner as
much as possible. My CascadePlanner inherits from the existing
VolcanoPlanner. Except that it overwrites ruleQueue and findBestPlan method
to rearrange rule applies, most logic generally inherit from
VolcanoPlanner. For example,
  - It reuses the RelSet and RelSubset class and the register method
  - Rules are fired as soon as a RelNode is registered (In the
Columnbia optimizer generator, rules are not fired until exploring). The
ApplyRule task controls when to invoke the onMatch method of a RuleMatch.
This design have a benefit that we do not need to worry about missing a
rule or firing a rule multiple times.
  - It leverages AbstractConverter to pass traits requirements down.  So
currently AC is still essential in my code.
This makes the new planner highly compatible with the old VolcanoPlanner.
Features like MV and Hints can apply to it directly.  And I tried to change
VolcanoPlanner to the new CascadePlanner in tests. Most tests passed.
Several cases did fail. I know the reason and how to fix them. But I am
still thinking about making them as "won't fix" as the ruleset violates
some basic principles of top-down trait requests.

The second difference is that our design have the ability for space
pruning. Currently it contains a simply LowerBoundCost metadata to compute
the lower bound of a RelNdoe. Because logical properties like cardinality
of a RelSet is not stable across exploring, it is required that a group to
be fully explored (implementation rules and enforcement rules should never
modify the logical properties) before it can provide a valid lower bound
cost. Because of that, logical search space pruning is not supported now.
It can only pruned out implementation rules and enforcement rules. Testing
with cases in our own product, the new planner saves about 10% rule
applies. I am still considering how to support logical space pruning,
looking forwards to have more improvements.

Hope my code will help.

Thanks,
Jinpeng


On Tue, Apr 28, 2020 at 11:22 AM Xiening Dai  wrote:

> For #1, aside from that we need to be able to build physical nodes based
> on a convention. For example, if we merge two EnumerableProject, we would
> want to create an EnumerableProject as a result, instead of LogicalProject.
> The RelBuilder change I work on would help this case.
>
> For #2, I don’t think it’s just a bug. If the physical cost cannot be
> reliable before transformation is finished, we should probably delay the
> physical cost calculation, or we risk doing it over again. The other way is
> to complete RelSet transformation before implementing it - which is a
> common practice in industry, including Orca.
>
> The multi-convention is a key scenario, and I agree we should support. My
> thinking is more about seperating logical one (Conventions.NONE) from
> others.
>
>
> > On Apr 27, 2020, at 4:59 PM, Julian Hyde  wrote:
> >
> > Re 1. By all means have multiple instances of a rule (e.g. one instance
> that matches LogicalFilter and another that matches FooFilter) and enable
> different instances during different phases. (We have been slow to create
> all of these variant instances, in part because of the difficulty of
> changing the constructors of many existing rules. My proposed change
> https://issues.apache.org/jira/browse/CALCITE-3923 <
> https://issues.apache.org/jira/browse/CALCITE-3923> would make it easier
> to create new instances that are more precisely targeted.)
> >
> > Re 2. Sure, there are bugs.
> >
> > Re 3. That’s a good idea. The planner could have a "single-convention
> mode", which might be faster, but would throw if it encountered a rel in a
> different convention.
> >
> > I think we’re in agreement - separating rules is a best practice. But we
> shouldn’t force that best practice on everyone. The multi-convention case
> is still crucial for planning hybrid queries (e.g. joining MySQL to
> MongoDB).
> >
> > Julian
> >
> >
> >> On Apr 27, 2020, at 4:28 PM, Xiening Dai  wrote:
> >>
> >> Hi Julian,
> >>
> >> In my view, separating logic and physical rules have a number of
> benefits -
> >>
> >> 1. With current design, a rule can match both physical and logical
> nodes. This behavior could cause duplication of rule firings and explosion
> of memo and search space. There was a long discussion regarding this
> 

Re: [Tests Failing] Master Travis test fails continuously for JDK14

[Danny Chan]

I have deleted the master cache, hope it helps ~

Best,
Danny Chan
在 2020年4月28日 +0800 AM10:53，Michael Mior ，写道：
> I have my accounts linked, but I see " Your permissions are
> insufficient to access this content."
> --
> Michael Mior
> mm...@apache.org
>
> Le lun. 27 avr. 2020 à 13:10, Kevin Risden  a écrit :
> >
> > We should be able to clear the Travis cache by ourselves.
> >
> > If you have your github and asf accounts linked:
> >
> > https://travis-ci.org/github/apache/calcite/caches
> >
> > That page is linked under the more options in the top right of the Calcite
> > page. You should be able to clear all or some subset of caches.
> >
> > Kevin Risden
> >
> >
> > On Mon, Apr 27, 2020 at 8:53 AM Vladimir Sitnikov <
> > sitnikov.vladi...@gmail.com> wrote:
> >
> > > > Log an issue there ?
> > >
> > > An issue for INFRA project would probably do:
> > > https://issues.apache.org/jira/projects/INFRA
> > >
> > > Vladimir
> > >

How to build and publish non-SNAPSHOT version?

[Laurent Goujon]

Hi,

I'd like to build my own non-SNAPSHOT version of Calcite and publish it in
my internal repository but I haven't found a way to do it with gradle. As
far as I can tell, there is a release plugin
(com.github.vlsi.stage-vote-release) which supports `-Prelease` property,
and will remove the -SNAPSHOT suffix, but it also triggers pushing to maven
central, git, svn, 

What I am looking for is a gradle command with  a couple of properties on
the commandline to specify the full version (or be able to change -SNAPSHOT
into something else) and push to my personal repository (something I was
able to do easily with the maven version).

Thanks in advance,

Laurent

Re: How to build and publish non-SNAPSHOT version?

[Julian Hyde]

I got some some advice from Vladimir, but ran into problems with
releases, as you did. I came up with this. Put the following in your
~/.gradle/init.gradle.kts file, and change the username and password:

allprojects {
plugins.withId("maven-publish") {
configure {
repositories {
maven {
name = "secretNexus"
val baseUrl = "https://nexusrepo.looker.com";
val releasesUrl = "$baseUrl/repository/maven-releases"
val snapshotsUrl = "$baseUrl/repository/maven-snapshots"
val release =
!project.version.toString().endsWith("-SNAPSHOT")
// val release = project.hasProperty("release")
url = uri(if (release) releasesUrl else snapshotsUrl)
credentials {
username = "xxx"
password = "xxx"
}
}
}
}
}
}

To deploy a release, do this:

./gradlew -Prelease -PskipSign publishAllPublicationsToSecretNexusRepository

If you like change 'secretNexus' to something more meaningful.

You'll probably also want to tag the release commit and push the tag
to your github fork.

Julian

On Tue, Apr 28, 2020 at 9:26 AM Laurent Goujon  wrote:
>
> Hi,
>
> I'd like to build my own non-SNAPSHOT version of Calcite and publish it in
> my internal repository but I haven't found a way to do it with gradle. As
> far as I can tell, there is a release plugin
> (com.github.vlsi.stage-vote-release) which supports `-Prelease` property,
> and will remove the -SNAPSHOT suffix, but it also triggers pushing to maven
> central, git, svn, 
>
> What I am looking for is a gradle command with  a couple of properties on
> the commandline to specify the full version (or be able to change -SNAPSHOT
> into something else) and push to my personal repository (something I was
> able to do easily with the maven version).
>
> Thanks in advance,
>
> Laurent

Re: How to build and publish non-SNAPSHOT version?

[Julian Hyde]

PS Oops. You'll obviously want to change

 val baseUrl = "https://nexusrepo.looker.com";

to reference your repo, not Looker's. :)

On Tue, Apr 28, 2020 at 9:36 AM Julian Hyde  wrote:
>
> I got some some advice from Vladimir, but ran into problems with
> releases, as you did. I came up with this. Put the following in your
> ~/.gradle/init.gradle.kts file, and change the username and password:
>
> allprojects {
> plugins.withId("maven-publish") {
> configure {
> repositories {
> maven {
> name = "secretNexus"
> val baseUrl = "https://nexusrepo.looker.com";
> val releasesUrl = "$baseUrl/repository/maven-releases"
> val snapshotsUrl = "$baseUrl/repository/maven-snapshots"
> val release =
> !project.version.toString().endsWith("-SNAPSHOT")
> // val release = project.hasProperty("release")
> url = uri(if (release) releasesUrl else snapshotsUrl)
> credentials {
> username = "xxx"
> password = "xxx"
> }
> }
> }
> }
> }
> }
>
> To deploy a release, do this:
>
> ./gradlew -Prelease -PskipSign publishAllPublicationsToSecretNexusRepository
>
> If you like change 'secretNexus' to something more meaningful.
>
> You'll probably also want to tag the release commit and push the tag
> to your github fork.
>
> Julian
>
> On Tue, Apr 28, 2020 at 9:26 AM Laurent Goujon  wrote:
> >
> > Hi,
> >
> > I'd like to build my own non-SNAPSHOT version of Calcite and publish it in
> > my internal repository but I haven't found a way to do it with gradle. As
> > far as I can tell, there is a release plugin
> > (com.github.vlsi.stage-vote-release) which supports `-Prelease` property,
> > and will remove the -SNAPSHOT suffix, but it also triggers pushing to maven
> > central, git, svn, 
> >
> > What I am looking for is a gradle command with  a couple of properties on
> > the commandline to specify the full version (or be able to change -SNAPSHOT
> > into something else) and push to my personal repository (something I was
> > able to do easily with the maven version).
> >
> > Thanks in advance,
> >
> > Laurent

Re: How to build and publish non-SNAPSHOT version?

[Laurent Goujon]

Thanks, very useful. Will give it a try.

On Tue, Apr 28, 2020 at 9:38 AM Julian Hyde  wrote:

> PS Oops. You'll obviously want to change
>
>  val baseUrl = "https://nexusrepo.looker.com";
>
> to reference your repo, not Looker's. :)
>
> On Tue, Apr 28, 2020 at 9:36 AM Julian Hyde  wrote:
> >
> > I got some some advice from Vladimir, but ran into problems with
> > releases, as you did. I came up with this. Put the following in your
> > ~/.gradle/init.gradle.kts file, and change the username and password:
> >
> > allprojects {
> > plugins.withId("maven-publish") {
> > configure {
> > repositories {
> > maven {
> > name = "secretNexus"
> > val baseUrl = "https://nexusrepo.looker.com";
> > val releasesUrl =
> "$baseUrl/repository/maven-releases"
> > val snapshotsUrl =
> "$baseUrl/repository/maven-snapshots"
> > val release =
> > !project.version.toString().endsWith("-SNAPSHOT")
> > // val release = project.hasProperty("release")
> > url = uri(if (release) releasesUrl else snapshotsUrl)
> > credentials {
> > username = "xxx"
> > password = "xxx"
> > }
> > }
> > }
> > }
> > }
> > }
> >
> > To deploy a release, do this:
> >
> > ./gradlew -Prelease -PskipSign
> publishAllPublicationsToSecretNexusRepository
> >
> > If you like change 'secretNexus' to something more meaningful.
> >
> > You'll probably also want to tag the release commit and push the tag
> > to your github fork.
> >
> > Julian
> >
> > On Tue, Apr 28, 2020 at 9:26 AM Laurent Goujon 
> wrote:
> > >
> > > Hi,
> > >
> > > I'd like to build my own non-SNAPSHOT version of Calcite and publish
> it in
> > > my internal repository but I haven't found a way to do it with gradle.
> As
> > > far as I can tell, there is a release plugin
> > > (com.github.vlsi.stage-vote-release) which supports `-Prelease`
> property,
> > > and will remove the -SNAPSHOT suffix, but it also triggers pushing to
> maven
> > > central, git, svn, 
> > >
> > > What I am looking for is a gradle command with  a couple of properties
> on
> > > the commandline to specify the full version (or be able to change
> -SNAPSHOT
> > > into something else) and push to my personal repository (something I
> was
> > > able to do easily with the maven version).
> > >
> > > Thanks in advance,
> > >
> > > Laurent
>

Re: How to build and publish non-SNAPSHOT version?

[Laurent Goujon]

quick followup: I usually encode the sha directly into the suffix for test
versions, so tagging into git has not been required until now.

On Tue, Apr 28, 2020 at 9:47 AM Laurent Goujon  wrote:

> Thanks, very useful. Will give it a try.
>
> On Tue, Apr 28, 2020 at 9:38 AM Julian Hyde  wrote:
>
>> PS Oops. You'll obviously want to change
>>
>>  val baseUrl = "https://nexusrepo.looker.com";
>>
>> to reference your repo, not Looker's. :)
>>
>> On Tue, Apr 28, 2020 at 9:36 AM Julian Hyde  wrote:
>> >
>> > I got some some advice from Vladimir, but ran into problems with
>> > releases, as you did. I came up with this. Put the following in your
>> > ~/.gradle/init.gradle.kts file, and change the username and password:
>> >
>> > allprojects {
>> > plugins.withId("maven-publish") {
>> > configure {
>> > repositories {
>> > maven {
>> > name = "secretNexus"
>> > val baseUrl = "https://nexusrepo.looker.com";
>> > val releasesUrl =
>> "$baseUrl/repository/maven-releases"
>> > val snapshotsUrl =
>> "$baseUrl/repository/maven-snapshots"
>> > val release =
>> > !project.version.toString().endsWith("-SNAPSHOT")
>> > // val release = project.hasProperty("release")
>> > url = uri(if (release) releasesUrl else
>> snapshotsUrl)
>> > credentials {
>> > username = "xxx"
>> > password = "xxx"
>> > }
>> > }
>> > }
>> > }
>> > }
>> > }
>> >
>> > To deploy a release, do this:
>> >
>> > ./gradlew -Prelease -PskipSign
>> publishAllPublicationsToSecretNexusRepository
>> >
>> > If you like change 'secretNexus' to something more meaningful.
>> >
>> > You'll probably also want to tag the release commit and push the tag
>> > to your github fork.
>> >
>> > Julian
>> >
>> > On Tue, Apr 28, 2020 at 9:26 AM Laurent Goujon 
>> wrote:
>> > >
>> > > Hi,
>> > >
>> > > I'd like to build my own non-SNAPSHOT version of Calcite and publish
>> it in
>> > > my internal repository but I haven't found a way to do it with
>> gradle. As
>> > > far as I can tell, there is a release plugin
>> > > (com.github.vlsi.stage-vote-release) which supports `-Prelease`
>> property,
>> > > and will remove the -SNAPSHOT suffix, but it also triggers pushing to
>> maven
>> > > central, git, svn, 
>> > >
>> > > What I am looking for is a gradle command with  a couple of
>> properties on
>> > > the commandline to specify the full version (or be able to change
>> -SNAPSHOT
>> > > into something else) and push to my personal repository (something I
>> was
>> > > able to do easily with the maven version).
>> > >
>> > > Thanks in advance,
>> > >
>> > > Laurent
>>
>

Re: How to build and publish non-SNAPSHOT version?

[Vladimir Sitnikov]

> a couple of properties on the commandline to specify the full version

The version comes from calcite.version property (see
https://github.com/apache/calcite/blob/e44beba286ea9049c5fd00c3a3b0e4a4f1c03356/gradle.properties#L26
)
so you can augment it via -Pcalcite.version=... on the command line.

By default it adds -SNAPSHOT, and, you can add -Prelease to make release
version.
The idea there is changing versions (e.g. snapshot vs release) can be done
without making code changes.

Vladimir

"calcite" and "calcite-examples" missing from release 1.22?

[Julian Hyde]

If you search for Calcite on Maven Central [1] you will see that the latest 
version of the “calcite” and “calcite-examples” artifacts is 1.21, whereas the 
latest version of everything else is 1.22.

Is this intended behavior, or a mistake introduced by the move to Gradle?

Julian

[1] https://search.maven.org/search?q=apache%20calcite 

Re: "calcite" and "calcite-examples" missing from release 1.22?

[Vladimir Sitnikov]

> If you search for Calcite on Maven Central [1] you will see that the
latest version of the “calcite” and “calcite-examples” artifacts is 1.21,
whereas the latest version of everything else is 1.22.

What is the purpose of "calcite" artifact?
Was
org.apache.calcitecalcite
useful?

A missing bit is the publishing of calcite-bom (bill-of-material).
It would be helpful for the consumers so they get all the versions of
-linq4j, -core, etc, by adding a single dependency on the bom artifact.
Here's the bom for JUnit5:
https://repo1.maven.org/maven2/org/junit/junit-bom/5.7.0-M1/junit-bom-5.7.0-M1.pom

Vladimir

Re: [DISCUSS] Towards Cascades Optimizer

[Roman Kondakov]

Hi Jinpeng,

I went through your PR and it seemed very impressive to me. It is very
similar to what I did, but you've reused many existing logic from the
Volcano planner. We should definitely stay in sync in our experiments. I
believe the future Cascades planner will be the kind combination of our
works.

Is there any way to run tests that are close to the real system query
execution? May be with Enumerable convention, or, better, with
convention that supports distribution trait? I just want to look through
your planner's optimization steps more thoroughly. I've found some tests
in org.apache.calcite.plan.volcano package, but they use synthetic
conventions and nodes. May be I missed something.

Thank you for sharing your work!

-- 
Kind Regards
Roman Kondakov


On 28.04.2020 15:19, Jinpeng Wu wrote:
> Hi, Roman. It's great to see your proposal. Actually my team has also been
> working on a cascade planner based on calcite.  And we already have some
> outcome as well.  Maybe we can combine our works.
> 
> I've pushed my code as https://github.com/apache/calcite/pull/1950 .
> 
> Our works have many places in common. We both developed a new
> CascadePlanner and avoid modifying the old VolcanoPlanner directly. We
> both implemented the top-down search strategy according to the
> Columnbia optimizer
> generator
> 。But
> we also have some differences.
> 
> The first difference is that I try to reuse the existing VolcanoPlanner as
> much as possible. My CascadePlanner inherits from the existing
> VolcanoPlanner. Except that it overwrites ruleQueue and findBestPlan method
> to rearrange rule applies, most logic generally inherit from
> VolcanoPlanner. For example,
>   - It reuses the RelSet and RelSubset class and the register method
>   - Rules are fired as soon as a RelNode is registered (In the
> Columnbia optimizer generator, rules are not fired until exploring). The
> ApplyRule task controls when to invoke the onMatch method of a RuleMatch.
> This design have a benefit that we do not need to worry about missing a
> rule or firing a rule multiple times.
>   - It leverages AbstractConverter to pass traits requirements down.  So
> currently AC is still essential in my code.
> This makes the new planner highly compatible with the old VolcanoPlanner.
> Features like MV and Hints can apply to it directly.  And I tried to change
> VolcanoPlanner to the new CascadePlanner in tests. Most tests passed.
> Several cases did fail. I know the reason and how to fix them. But I am
> still thinking about making them as "won't fix" as the ruleset violates
> some basic principles of top-down trait requests.
> 
> The second difference is that our design have the ability for space
> pruning. Currently it contains a simply LowerBoundCost metadata to compute
> the lower bound of a RelNdoe. Because logical properties like cardinality
> of a RelSet is not stable across exploring, it is required that a group to
> be fully explored (implementation rules and enforcement rules should never
> modify the logical properties) before it can provide a valid lower bound
> cost. Because of that, logical search space pruning is not supported now.
> It can only pruned out implementation rules and enforcement rules. Testing
> with cases in our own product, the new planner saves about 10% rule
> applies. I am still considering how to support logical space pruning,
> looking forwards to have more improvements.
> 
> Hope my code will help.
> 
> Thanks,
> Jinpeng
> 
> 
> On Tue, Apr 28, 2020 at 11:22 AM Xiening Dai  wrote:
> 
>> For #1, aside from that we need to be able to build physical nodes based
>> on a convention. For example, if we merge two EnumerableProject, we would
>> want to create an EnumerableProject as a result, instead of LogicalProject.
>> The RelBuilder change I work on would help this case.
>>
>> For #2, I don’t think it’s just a bug. If the physical cost cannot be
>> reliable before transformation is finished, we should probably delay the
>> physical cost calculation, or we risk doing it over again. The other way is
>> to complete RelSet transformation before implementing it - which is a
>> common practice in industry, including Orca.
>>
>> The multi-convention is a key scenario, and I agree we should support. My
>> thinking is more about seperating logical one (Conventions.NONE) from
>> others.
>>
>>
>>> On Apr 27, 2020, at 4:59 PM, Julian Hyde  wrote:
>>>
>>> Re 1. By all means have multiple instances of a rule (e.g. one instance
>> that matches LogicalFilter and another that matches FooFilter) and enable
>> different instances during different phases. (We have been slow to create
>> all of these variant instances, in part because of the difficulty of
>> changing the constructors of many existing rules. My proposed change
>> https://issues.apache.org/jira/browse/CALCITE-3923 <
>> https://issues.apache.org/jira/browse/CALCITE-3923> would ma

Re: [DISCUSS] Towards Cascades Optimizer

[Roman Kondakov]

Hi Xiening,

thank you for your feedback.

> 1. Do we really need RelGroup and RelSubGroup? I believe the memo structure 
> would be largely the same even if we move towards a Cascade planner. I think 
> we can reuse most of the RelSet/RelSubset today. RelSubset is a tricky one. 
> There’s no corresponding concept in the Cascade framework. But we do need a 
> way to track the RelNode physical traits anyway. A RelSubset is more like a 
> logical grouping of the RelNodes with same trait set, which I think is still 
> valuable.

No, we don't really need RelGroup and RelSubGroup. My initial approach
was to use only RelGroup as in original Cascades framework, but later I
realized that RelSubGroup is a convenient concept and introduced it. I'm
going to replace both with RelSet/RelSubset later. Despite
RelSet/RelSubset have many things that not needed for cascades (parents,
propagateCosImprovements, etc).

> Keeping backward compatibility is a key goal. We have to think through this 
> at the very beginning of the design. The community has invested a lot with 
> Volcano planner over the years. We cannot ask people to rewrite their rules 
> just to make them work with the new planner. We should expect current rules 
> would just work, or would work with “minimal” changes.

I agree with you. My next step is to bring backward compatibility for
Cascades planner.

> There are some building blocks that are currently missing which will prevent 
> us from using the Cascade top down search strategy. For example, the way how 
> rule is matched, the lack of transformation phase, the lack of the ability to 
> create physical nodes by the framework, etc. If we don’t care about current 
> rules, and start from scratch, we probably don’t need to fix these issues. 
> But with #2 in mind, we have to work out solutions for these so we can carry 
> over existing rules.

I think we can reuse existing rules and at the same time achieve correct
top-down Cascades search strategy. For example, I've changed rule
matching strategy in the prototype: rules are matched on demand in the
top-down way (see org.apache.calcite.plan.cascades.ApplyRule.Bindery
class). And I believe that all other things (like creating physical
nodes) we can fix in the similar way: just changing the planner code
while maintaining backward compatibility.


-- 
Kind Regards
Roman Kondakov


On 28.04.2020 03:12, Xiening Dai wrote:
> Hi Roman,
> 
> First, thank you for sharing your design and prototype code. I took a quick 
> look at your design and have some high level feedback -
> 
> 1. Do we really need RelGroup and RelSubGroup? I believe the memo structure 
> would be largely the same even if we move towards a Cascade planner. I think 
> we can reuse most of the RelSet/RelSubset today. RelSubset is a tricky one. 
> There’s no corresponding concept in the Cascade framework. But we do need a 
> way to track the RelNode physical traits anyway. A RelSubset is more like a 
> logical grouping of the RelNodes with same trait set, which I think is still 
> valuable.
> 
> 2. Keeping backward compatibility is a key goal. We have to think through 
> this at the very beginning of the design. The community has invested a lot 
> with Volcano planner over the years. We cannot ask people to rewrite their 
> rules just to make them work with the new planner. We should expect current 
> rules would just work, or would work with “minimal” changes.
> 
> 3. There are some building blocks that are currently missing which will 
> prevent us from using the Cascade top down search strategy. For example, the 
> way how rule is matched, the lack of transformation phase, the lack of the 
> ability to create physical nodes by the framework, etc. If we don’t care 
> about current rules, and start from scratch, we probably don’t need to fix 
> these issues. But with #2 in mind, we have to work out solutions for these so 
> we can carry over existing rules.
> 
> I think your execution plan looks good overall. We can iterate on the design 
> while working out a document.
> 
> For the purpose of transparency, I’ve been working with Haisheng in the last 
> few months regarding this topics. I agree with him on most parts of his 
> roadmap, which I think it’s a tangible plan to evolve current Volcano planner.
> 
> 
>> On Apr 27, 2020, at 11:29 AM, Roman Kondakov  
>> wrote:
>>
>> Hi all,
>>
>> Stamatis, Haisheng thank you very much for your feedback! I really
>> appreciate it.
>>
>>> If in the new planner we end up copy-pasting code then I guess it will be a 
>>> bad idea.
>>
>> Yes, there are some code duplication between Volcano planner and
>> Cascades planner. I think I'll move it to some common superclass: either
>> to existing AbstractRelOptPlanner or a new AbstractCostBasedPlanner.
>>
>>> Like that it will be easier for everybody to test and see if the changes 
>>> make this better or worse. From a backward compatibility perspective it 
>>> seems feasible to keep the new eatures configurable for 

[ANNOUNCE] New committer: Jin Xing

[Stamatis Zampetakis]

Apache Calcite's Project Management Committee (PMC) has invited Jin Xing to
become a committer, and we are pleased to announce that he has accepted.

Jin has contributed a lot of code in the project and many
recent improvements in
materialized view matching have his signature on them. Apart from code
contributions, Jin provides valuable help to the community by doing reviews
and
answering questions in the devlist.

Jin, welcome, thank you for your contributions, and we look forward to your
further interactions with the community! If you wish, please feel free to
tell
us more about yourself and what you are working on.

Stamatis (on behalf of the Apache Calcite PMC)

[ANNOUNCE] New committer: Wang Yanlin

[Stamatis Zampetakis]

Apache Calcite's Project Management Committee (PMC) has invited Wang Yanlin
to
become a committer, and we are pleased to announce that he has accepted.

Wang has pushed numerous fixes and improvements to the project, landing in
total
the impressive number of 30 commits to the master. Among other things, he
contributed some important features in the Interpreter.

Wang, welcome, thank you for your contributions, and we look forward your
further interactions with the community! If you wish, please feel free to
tell
us more about yourself and what you are working on.

Stamatis (on behalf of the Apache Calcite PMC)

[ANNOUNCE] New committer: Forward Xu

[Stamatis Zampetakis]

Apache Calcite's Project Management Committee (PMC) has invited Forward Xu
to
become a committer, and we are pleased to announce that he has accepted.

Forward has been helping the project for some time now. He added many new
SQL
functions to the project and is one of our JSON experts. On top of that, and
other fixes, he is the one who added the Redis adapter to the project.

Forward, welcome, thank you for your contributions, and we look forward to
your
further interactions with the community! If you wish, please feel free to
tell
us more about yourself and what you are working on.

Stamatis (on behalf of the Apache Calcite PMC)

Re: [ANNOUNCE] New committer: Wang Yanlin

[Francis Chuang]

Congrats, Wang!

Francis

On 29/04/2020 7:50 am, Stamatis Zampetakis wrote:

Apache Calcite's Project Management Committee (PMC) has invited Wang Yanlin
to
become a committer, and we are pleased to announce that he has accepted.

Wang has pushed numerous fixes and improvements to the project, landing in
total
the impressive number of 30 commits to the master. Among other things, he
contributed some important features in the Interpreter.

Wang, welcome, thank you for your contributions, and we look forward your
further interactions with the community! If you wish, please feel free to
tell
us more about yourself and what you are working on.

Stamatis (on behalf of the Apache Calcite PMC)

Re: [ANNOUNCE] New committer: Jin Xing

[Francis Chuang]

Congrats, Jin!

On 29/04/2020 7:47 am, Stamatis Zampetakis wrote:

Apache Calcite's Project Management Committee (PMC) has invited Jin Xing to
become a committer, and we are pleased to announce that he has accepted.

Jin has contributed a lot of code in the project and many
recent improvements in
materialized view matching have his signature on them. Apart from code
contributions, Jin provides valuable help to the community by doing reviews
and
answering questions in the devlist.

Jin, welcome, thank you for your contributions, and we look forward to your
further interactions with the community! If you wish, please feel free to
tell
us more about yourself and what you are working on.

Stamatis (on behalf of the Apache Calcite PMC)

Re: [ANNOUNCE] New committer: Forward Xu

[Francis Chuang]

Congrats, Forward!

Francis

On 29/04/2020 7:53 am, Stamatis Zampetakis wrote:

Apache Calcite's Project Management Committee (PMC) has invited Forward Xu
to
become a committer, and we are pleased to announce that he has accepted.

Forward has been helping the project for some time now. He added many new
SQL
functions to the project and is one of our JSON experts. On top of that, and
other fixes, he is the one who added the Redis adapter to the project.

Forward, welcome, thank you for your contributions, and we look forward to
your
further interactions with the community! If you wish, please feel free to
tell
us more about yourself and what you are working on.

Stamatis (on behalf of the Apache Calcite PMC)

Re: [DICUSS] Support building physical RelNode in Calcite

[Stamatis Zampetakis]

Hello,

I've seen that parts from this discussion have moved to another thread [1].
I decided to reply in this thread in an attempt to not deviate a lot the
discussion in [1], which I feel is more general than the problems mentioned
here.

Getting things from the beginning, Xiening mentioned three drawbacks but I
would say that we are mostly bothered by number 1.

For the second drawback, the fact that we use rules to transform a
LogicalFilter to an EnumerableFilter is not a big issue from my point of
view. If the plan is to register a special builder in the planner to
replace these rules then it seems that we move the code from one place to
another. Plus, if we cannot replace all the rules of Logical to Enumerable
and we split the logic into two places then the code will be more difficult
to understand.

For the third drawback, I would say that it is mostly a problem of the
adapter. Every rule accepts a RelBuilderFactory so if the adapter wants to
create physical nodes it should pass an appropriate factory to the
respective rules. Recently in [1], and other times in the past, it was
brought up as a problem that ProjectMergeRule (and other similar kind of
rules) match Enumerable nodes and create Logical ones. I would say that
this is mostly a bad configuration rather than a problem that should be
resolved automatically by the planner. Avoiding the aforementioned behavior
does not look very complicated; we need to instantiate the rule so that it
matches EnumerableProject and uses a RelBuilderFactory that creates
Enumerable operators.

>From my last comment, I think it is evident that I am also leaning to the
direction outlined by Julian, a RelBuilder capable of creating many
physical operators.

It's been a while that I didn't check the progress in [2] so apologies if
what I wrote here is obsolete.

Best,
Stamatis

[1]
https://lists.apache.org/thread.html/r38ea71968c069f465921e7197488329c15413b46831c90ad4d48f87e%40%3Cdev.calcite.apache.org%3E
[2] https://github.com/apache/calcite/pull/1884

On Thu, Apr 9, 2020, 12:57 AM Julian Hyde  wrote:

> It's challenging to support all physical operators, but we can and
> should support many of them in RelBuilder.
>
> As Haisheng points out, some physical operators have extra operands.
> Maybe some of those operands can be added to the factory interfaces,
> or shoe-horned in in some clever way. (Note how we represent ASC and
> DESC keywords in RelBuilder.sort(RexNode...) as if they were function
> calls, or made RelBuilder.AggCall a fluent API to accommodate the many
> possible operands of an aggregate function call.)
>
> Many physical operators do not have extra operands. They implement the
> same contract as the logical operator, but with different physical
> properties (traits) (e.g. in a different convention, or assuming the
> input is sorted or partitioned in a particular way). The "operands" to
> these operands are the physical properties that they consume and
> produce.
>
> But conversely, there are huge benefits to sharing the code involved
> in creating RelNodes. A HashAggregate physical operator has a lot in
> common with LogicalAggregate, so can benefit from the same code.
> Without RelBuilder (or its embedded helper objects like RexSimplifier)
> being the place to put that logic, it will end up being spread out
> over, and duplicated in, many RelOptRule instances.
>
> We should be ambitious, and aim to make RelBuilder useful for creating
> most physical nodes. Perhaps make modest extensions to RelBuilder and
> RelFactory APIs to achieve this. If we fail, people can still manually
> create RelNodes using RelBuilder.push().
>
> Julian
>
>
> On Wed, Apr 8, 2020 at 10:07 AM Xiening Dai  wrote:
> >
> > Yes, this is a good question. I think it would be up to the builder
> factory to decide. One can just create a logical join if it couldn’t decide
> which join algorithm to use. Then the withConvention() syntax does not
> provide guarantees. The caller will need an assert if they expect the
> RelNode returned to have the requested convention.
> >
> > I think eventually it comes down to how we define the role of
> RelBuilder. Now it does look like it's doing some simple logical
> transformation (see filter() and sort()).
> >
> > > On Apr 7, 2020, at 5:43 PM, Haisheng Yuan 
> wrote:
> > >
> > > Thanks Xiening for moving this to dev list.
> > >
> > > Unlike logical operators, with which many systems share the same
> structure, physical operators are pretty implementation dependent.
> RelBuilder provides the common interface to create aggregate, join. But
> what kind of physical aggregate? HashAgg, StreamAgg? How do I specify it as
> a local aggregate, or global aggregate? In many cases, these physical
> operator constructors have system dependent arguments, will the RelBuilder
> support these? Shuffle / Exchange operator of different system may also
> differ on their arguments.
> > >
> > > The worst case is that only physical filter, project, sort can be
> created usi

Re: [DICUSS] Support building physical RelNode in Calcite

[Xiening Dai]

Thanks Stamatis. Sorry there have been a few threads going on in parallel. 

I’ve a PR currently under review. It’s based on suggestions from Julian and 
Haisheng. You can take a look if you are interested. Initial test result shows 
very promising improvement.

https://github.com/apache/calcite/pull/1884#pullrequestreview-402251279 



> On Apr 28, 2020, at 3:34 PM, Stamatis Zampetakis  wrote:
> 
> Hello,
> 
> I've seen that parts from this discussion have moved to another thread [1].
> I decided to reply in this thread in an attempt to not deviate a lot the
> discussion in [1], which I feel is more general than the problems mentioned
> here.
> 
> Getting things from the beginning, Xiening mentioned three drawbacks but I
> would say that we are mostly bothered by number 1.
> 
> For the second drawback, the fact that we use rules to transform a
> LogicalFilter to an EnumerableFilter is not a big issue from my point of
> view. If the plan is to register a special builder in the planner to
> replace these rules then it seems that we move the code from one place to
> another. Plus, if we cannot replace all the rules of Logical to Enumerable
> and we split the logic into two places then the code will be more difficult
> to understand.
> 
> For the third drawback, I would say that it is mostly a problem of the
> adapter. Every rule accepts a RelBuilderFactory so if the adapter wants to
> create physical nodes it should pass an appropriate factory to the
> respective rules. Recently in [1], and other times in the past, it was
> brought up as a problem that ProjectMergeRule (and other similar kind of
> rules) match Enumerable nodes and create Logical ones. I would say that
> this is mostly a bad configuration rather than a problem that should be
> resolved automatically by the planner. Avoiding the aforementioned behavior
> does not look very complicated; we need to instantiate the rule so that it
> matches EnumerableProject and uses a RelBuilderFactory that creates
> Enumerable operators.
> 
> From my last comment, I think it is evident that I am also leaning to the
> direction outlined by Julian, a RelBuilder capable of creating many
> physical operators.
> 
> It's been a while that I didn't check the progress in [2] so apologies if
> what I wrote here is obsolete.
> 
> Best,
> Stamatis
> 
> [1]
> https://lists.apache.org/thread.html/r38ea71968c069f465921e7197488329c15413b46831c90ad4d48f87e%40%3Cdev.calcite.apache.org%3E
> [2] https://github.com/apache/calcite/pull/1884
> 
> On Thu, Apr 9, 2020, 12:57 AM Julian Hyde  wrote:
> 
>> It's challenging to support all physical operators, but we can and
>> should support many of them in RelBuilder.
>> 
>> As Haisheng points out, some physical operators have extra operands.
>> Maybe some of those operands can be added to the factory interfaces,
>> or shoe-horned in in some clever way. (Note how we represent ASC and
>> DESC keywords in RelBuilder.sort(RexNode...) as if they were function
>> calls, or made RelBuilder.AggCall a fluent API to accommodate the many
>> possible operands of an aggregate function call.)
>> 
>> Many physical operators do not have extra operands. They implement the
>> same contract as the logical operator, but with different physical
>> properties (traits) (e.g. in a different convention, or assuming the
>> input is sorted or partitioned in a particular way). The "operands" to
>> these operands are the physical properties that they consume and
>> produce.
>> 
>> But conversely, there are huge benefits to sharing the code involved
>> in creating RelNodes. A HashAggregate physical operator has a lot in
>> common with LogicalAggregate, so can benefit from the same code.
>> Without RelBuilder (or its embedded helper objects like RexSimplifier)
>> being the place to put that logic, it will end up being spread out
>> over, and duplicated in, many RelOptRule instances.
>> 
>> We should be ambitious, and aim to make RelBuilder useful for creating
>> most physical nodes. Perhaps make modest extensions to RelBuilder and
>> RelFactory APIs to achieve this. If we fail, people can still manually
>> create RelNodes using RelBuilder.push().
>> 
>> Julian
>> 
>> 
>> On Wed, Apr 8, 2020 at 10:07 AM Xiening Dai  wrote:
>>> 
>>> Yes, this is a good question. I think it would be up to the builder
>> factory to decide. One can just create a logical join if it couldn’t decide
>> which join algorithm to use. Then the withConvention() syntax does not
>> provide guarantees. The caller will need an assert if they expect the
>> RelNode returned to have the requested convention.
>>> 
>>> I think eventually it comes down to how we define the role of
>> RelBuilder. Now it does look like it's doing some simple logical
>> transformation (see filter() and sort()).
>>> 
 On Apr 7, 2020, at 5:43 PM, Haisheng Yuan 
>> wrote:
 
 Thanks Xiening for moving this to dev list.
 
 Unlike logical op

Re: [ANNOUNCE] New committer: Forward Xu

[Rui Wang]

Congrats!


-Rui

On Tue, Apr 28, 2020 at 3:04 PM Francis Chuang 
wrote:

> Congrats, Forward!
>
> Francis
>
> On 29/04/2020 7:53 am, Stamatis Zampetakis wrote:
> > Apache Calcite's Project Management Committee (PMC) has invited Forward
> Xu
> > to
> > become a committer, and we are pleased to announce that he has accepted.
> >
> > Forward has been helping the project for some time now. He added many new
> > SQL
> > functions to the project and is one of our JSON experts. On top of that,
> and
> > other fixes, he is the one who added the Redis adapter to the project.
> >
> > Forward, welcome, thank you for your contributions, and we look forward
> to
> > your
> > further interactions with the community! If you wish, please feel free to
> > tell
> > us more about yourself and what you are working on.
> >
> > Stamatis (on behalf of the Apache Calcite PMC)
> >
>

Re: [ANNOUNCE] New committer: Jin Xing

[Rui Wang]

Congrats, Jin!



-Rui

On Tue, Apr 28, 2020 at 3:03 PM Francis Chuang 
wrote:

> Congrats, Jin!
>
> On 29/04/2020 7:47 am, Stamatis Zampetakis wrote:
> > Apache Calcite's Project Management Committee (PMC) has invited Jin Xing
> to
> > become a committer, and we are pleased to announce that he has accepted.
> >
> > Jin has contributed a lot of code in the project and many
> > recent improvements in
> > materialized view matching have his signature on them. Apart from code
> > contributions, Jin provides valuable help to the community by doing
> reviews
> > and
> > answering questions in the devlist.
> >
> > Jin, welcome, thank you for your contributions, and we look forward to
> your
> > further interactions with the community! If you wish, please feel free to
> > tell
> > us more about yourself and what you are working on.
> >
> > Stamatis (on behalf of the Apache Calcite PMC)
> >
>

Re: [ANNOUNCE] New committer: Wang Yanlin

[Rui Wang]

Congrats, Yanlin!



-Rui

On Tue, Apr 28, 2020 at 3:04 PM Francis Chuang 
wrote:

> Congrats, Wang!
>
> Francis
>
> On 29/04/2020 7:50 am, Stamatis Zampetakis wrote:
> > Apache Calcite's Project Management Committee (PMC) has invited Wang
> Yanlin
> > to
> > become a committer, and we are pleased to announce that he has accepted.
> >
> > Wang has pushed numerous fixes and improvements to the project, landing
> in
> > total
> > the impressive number of 30 commits to the master. Among other things, he
> > contributed some important features in the Interpreter.
> >
> > Wang, welcome, thank you for your contributions, and we look forward your
> > further interactions with the community! If you wish, please feel free to
> > tell
> > us more about yourself and what you are working on.
> >
> > Stamatis (on behalf of the Apache Calcite PMC)
> >
>

Re: [DISCUSS] Deprecate grouped window functions

[Rui Wang]

Agreed. I would like to get more feedback to have a
reasonable accommodation for users.


-Rui

On Mon, Apr 27, 2020 at 11:50 AM Julian Hyde  wrote:

> Changing my +1 to +0. We have to make reasonable accommodations for our
> users. Glad we had this discussion.
>
> > On Apr 24, 2020, at 11:10 AM, Rui Wang  wrote:
> >
> > Hi Timo,
> >
> > My intention is to fully drop concepts such as SqlGroupedWindowFunction
> and
> > auxiliary group functions, which include relevant code in parser/syntax,
> > operator, planner, etc.
> >
> > Since you mentioned the need for more time to migrate. How many Calcite
> > releases that you think can probably leave enough buffer time? (Calcite
> > schedules 4 releases a year. So say 2 releases will give 6 months)
> >
> >
> > -Rui
> >
> > On Fri, Apr 24, 2020 at 1:50 AM Timo Walther  wrote:
> >
> >> Hi everyone,
> >>
> >> so far Apache Flink depends on this feature. We are fine with improving
> >> the SQL compliance and eventually dropping GROUP BY TUMBLE/HOP/SESSION
> >> in the future. However, we would like to give our users some time to
> >> migrate their existing pipelines.
> >>
> >> What does dropping mean for Calcite? Will users of Calcite be able to
> >> still support this syntax? In particular, are you intending to also drop
> >> concepts such as SqlGroupedWindowFunction and auxiliary group functions?
> >> Or are you intending to just remove entries from Calcite's default
> >> operator table?
> >>
> >> Regards,
> >> Timo
> >>
> >>
> >> On 24.04.20 10:30, Julian Hyde wrote:
> >>> +1
> >>>
> >>> Let’s remove TUMBLE etc from the GROUP BY clause. Since this is a SQL
> >> change, not an API change, I don’t we need to give notice. Let’s just
> do it.
> >>>
> >>> Julian
> >>>
>  On Apr 22, 2020, at 4:05 PM, Rui Wang  wrote:
> 
>  Made a mistake on the example above, and update it as follows:
> 
>  // Table function windowing syntax.
>  SELECT
> product_id, count(*), window_start
>  FROM TABLE(TUMBLE(order, DESCRIPTOR(rowtime), INTERVAL '1' hour))
>  GROUP BY product_id, window_start
> 
> > On Wed, Apr 22, 2020 at 2:31 PM Rui Wang 
> wrote:
> >
> > Hi community,
> >
> > I want to kick off a discussion about deprecating grouped window
> >> functions
> > (GROUP BY TUMBLE/HOP/SESSION) as the table function windowing support
> > becomes a thing [1] (FROM TABLE(TUMBLE/HOP/SESSION)). The current
> >> stage of
> > table function windowing is TUMBLE support is checked in. HOP and
> >> SESSION
> > support is likely to be merged in 1.23.0.
> >
> > A briefly example of two different windowing syntax:
> >
> > // Grouped window functions.
> > SELECT
> >   product_id, count(*), TUMBLE_START() as window_start
> > FROM order
> > GROUP BY product_id, TUMBLE(rowtime, INTERVAL '1' hour); // an hour
> >> long
> > fixed window size.
> >
> > // Table function windowing syntax.
> > SELECT
> >product_id, count(*), window_start
> > FROM TABLE(TUMBLE(order, DESCRIPTOR(.rowtime), INTERVAL '1' hour)
> > GROUP BY product_id
> >
> > I am giving a short, selective comparison as the following:
> >
> > The places that table function windowing behaves better
> > 1) no GROUPING/GROUP BY enforced. It becomes a problem in streaming
> >> JOIN.
> > For example, one use case is for each hour, apply a JOIN on two
> >> streams. In
> > this case, no GROUP BY is needed.
> > 2) grouped window functions allow multiple calls in GROUP BY. For
> >> example,
> > from SQL syntax perspective, GROUP BY TUMBLE(...), HOP(...),
> >> SESSION(...)
> > is not wrong, but it is an illegal query.
> > 3) Calcite includes an Enumerable implementation of table function
> > windowing, while grouped window functions do not have that.
> >
> >
> > The places that table function windowing behaves worse
> > 1) table function windowing adds "window_start", "window_end" into
> >> table
> > directly, which increases the volume of data (number of rows *
> > sizeof(timestamp) * 2).
> >
> >
> > I want to focus on discussing two questions in this thread:
> > 1) Do people support deprecating grouped window functions?
> > 2) By which version people prefer to make grouped window functions
> > completely removed?(if 1) is yes).
> >
> >
> >
> > [1]: https://jira.apache.org/jira/browse/CALCITE-3271
> >
> >
> > -Rui
> >
> >>
> >>
>
>

Calcite-Master - Build # 1724 - Failure

[Apache Jenkins Server]

The Apache Jenkins build system has built Calcite-Master (build #1724)

Status: Failure

Check console output at https://builds.apache.org/job/Calcite-Master/1724/ to 
view the results.

Re: [ANNOUNCE] New committer: Jin Xing

[953396112]

Congrats, Jin Xing!


---Original---
From: "Stamatis Zampetakis"

Re: [ANNOUNCE] New committer: Wang Yanlin

[953396112]

Congrats, Wang Yanlin!




---Original---
From: "Stamatis Zampetakis"

Re: [ANNOUNCE] New committer: Wang Yanlin

[Forward Xu]

Congrats


Best,

Forward

953396112 <953396...@qq.com> 于2020年4月29日周三 上午8:26写道：

> Congrats, Wang Yanlin!
>
>
>
>
> ---Original---
> From: "Stamatis Zampetakis" Date: Wed, Apr 29, 2020 05:51 AM
> To: "dev" Subject: [ANNOUNCE] New committer: Wang Yanlin
>
>
> Apache Calcite's Project Management Committee (PMC) has invited Wang Yanlin
> to
> become a committer, and we are pleased to announce that he has accepted.
>
> Wang has pushed numerous fixes and improvements to the project, landing in
> total
> the impressive number of 30 commits to the master. Among other things, he
> contributed some important features in the Interpreter.
>
> Wang, welcome, thank you for your contributions, and we look forward your
> further interactions with the community! If you wish, please feel free to
> tell
> us more about yourself and what you are working on.
>
> Stamatis (on behalf of the Apache Calcite PMC)

Re: [ANNOUNCE] New committer: Jin Xing

[Forward Xu]

Congrats


best,

Forward

953396112 <953396...@qq.com> 于2020年4月29日周三 上午8:21写道：

> Congrats, Jin Xing!
>
>
> ---Original---
> From: "Stamatis Zampetakis" Date: Wed, Apr 29, 2020 05:47 AM
> To: "dev" Subject: [ANNOUNCE] New committer: Jin Xing
>
>
> Apache Calcite's Project Management Committee (PMC) has invited Jin Xing to
> become a committer, and we are pleased to announce that he has accepted.
>
> Jin has contributed a lot of code in the project and many
> recent improvements in
> materialized view matching have his signature on them. Apart from code
> contributions, Jin provides valuable help to the community by doing reviews
> and
> answering questions in the devlist.
>
> Jin, welcome, thank you for your contributions, and we look forward to your
> further interactions with the community! If you wish, please feel free to
> tell
> us more about yourself and what you are working on.
>
> Stamatis (on behalf of the Apache Calcite PMC)

Re: [ANNOUNCE] New committer: Jin Xing

[Chunwei Lei]

Congrats, Jin!


Best,
Chunwei


On Wed, Apr 29, 2020 at 10:07 AM Forward Xu  wrote:

> Congrats
>
>
> best,
>
> Forward
>
> 953396112 <953396...@qq.com> 于2020年4月29日周三 上午8:21写道：
>
> > Congrats, Jin Xing!
> >
> >
> > ---Original---
> > From: "Stamatis Zampetakis" > Date: Wed, Apr 29, 2020 05:47 AM
> > To: "dev" > Subject: [ANNOUNCE] New committer: Jin Xing
> >
> >
> > Apache Calcite's Project Management Committee (PMC) has invited Jin Xing
> to
> > become a committer, and we are pleased to announce that he has accepted.
> >
> > Jin has contributed a lot of code in the project and many
> > recent improvements in
> > materialized view matching have his signature on them. Apart from code
> > contributions, Jin provides valuable help to the community by doing
> reviews
> > and
> > answering questions in the devlist.
> >
> > Jin, welcome, thank you for your contributions, and we look forward to
> your
> > further interactions with the community! If you wish, please feel free to
> > tell
> > us more about yourself and what you are working on.
> >
> > Stamatis (on behalf of the Apache Calcite PMC)
>

Re: [ANNOUNCE] New committer: Wang Yanlin

[Chunwei Lei]

Congrats, Yanlin!


Best,
Chunwei


On Wed, Apr 29, 2020 at 10:07 AM Forward Xu  wrote:

> Congrats
>
>
> Best,
>
> Forward
>
> 953396112 <953396...@qq.com> 于2020年4月29日周三 上午8:26写道：
>
> > Congrats, Wang Yanlin!
> >
> >
> >
> >
> > ---Original---
> > From: "Stamatis Zampetakis" > Date: Wed, Apr 29, 2020 05:51 AM
> > To: "dev" > Subject: [ANNOUNCE] New committer: Wang Yanlin
> >
> >
> > Apache Calcite's Project Management Committee (PMC) has invited Wang
> Yanlin
> > to
> > become a committer, and we are pleased to announce that he has accepted.
> >
> > Wang has pushed numerous fixes and improvements to the project, landing
> in
> > total
> > the impressive number of 30 commits to the master. Among other things, he
> > contributed some important features in the Interpreter.
> >
> > Wang, welcome, thank you for your contributions, and we look forward your
> > further interactions with the community! If you wish, please feel free to
> > tell
> > us more about yourself and what you are working on.
> >
> > Stamatis (on behalf of the Apache Calcite PMC)
>

Re: [ANNOUNCE] New committer: Forward Xu

[Chunwei Lei]

Congrats, Forward!



Best,
Chunwei


On Wed, Apr 29, 2020 at 6:46 AM Rui Wang  wrote:

> Congrats!
>
>
> -Rui
>
> On Tue, Apr 28, 2020 at 3:04 PM Francis Chuang 
> wrote:
>
> > Congrats, Forward!
> >
> > Francis
> >
> > On 29/04/2020 7:53 am, Stamatis Zampetakis wrote:
> > > Apache Calcite's Project Management Committee (PMC) has invited Forward
> > Xu
> > > to
> > > become a committer, and we are pleased to announce that he has
> accepted.
> > >
> > > Forward has been helping the project for some time now. He added many
> new
> > > SQL
> > > functions to the project and is one of our JSON experts. On top of
> that,
> > and
> > > other fixes, he is the one who added the Redis adapter to the project.
> > >
> > > Forward, welcome, thank you for your contributions, and we look forward
> > to
> > > your
> > > further interactions with the community! If you wish, please feel free
> to
> > > tell
> > > us more about yourself and what you are working on.
> > >
> > > Stamatis (on behalf of the Apache Calcite PMC)
> > >
> >
>

Re: [ANNOUNCE] New committer: Wang Yanlin

[Feng Zhu]

 Congrations! Yanlin!

best,
Feng

Chunwei Lei  于2020年4月29日周三 上午10:16写道：

> Congrats, Yanlin!
>
>
> Best,
> Chunwei
>
>
> On Wed, Apr 29, 2020 at 10:07 AM Forward Xu 
> wrote:
>
> > Congrats
> >
> >
> > Best,
> >
> > Forward
> >
> > 953396112 <953396...@qq.com> 于2020年4月29日周三 上午8:26写道：
> >
> > > Congrats, Wang Yanlin!
> > >
> > >
> > >
> > >
> > > ---Original---
> > > From: "Stamatis Zampetakis" > > Date: Wed, Apr 29, 2020 05:51 AM
> > > To: "dev" > > Subject: [ANNOUNCE] New committer: Wang Yanlin
> > >
> > >
> > > Apache Calcite's Project Management Committee (PMC) has invited Wang
> > Yanlin
> > > to
> > > become a committer, and we are pleased to announce that he has
> accepted.
> > >
> > > Wang has pushed numerous fixes and improvements to the project, landing
> > in
> > > total
> > > the impressive number of 30 commits to the master. Among other things,
> he
> > > contributed some important features in the Interpreter.
> > >
> > > Wang, welcome, thank you for your contributions, and we look forward
> your
> > > further interactions with the community! If you wish, please feel free
> to
> > > tell
> > > us more about yourself and what you are working on.
> > >
> > > Stamatis (on behalf of the Apache Calcite PMC)
> >
>

Re: [ANNOUNCE] New committer: Jin Xing

[Feng Zhu]

 Congrations!

best,
Feng

Chunwei Lei  于2020年4月29日周三 上午10:16写道：

> Congrats, Jin!
>
>
> Best,
> Chunwei
>
>
> On Wed, Apr 29, 2020 at 10:07 AM Forward Xu 
> wrote:
>
> > Congrats
> >
> >
> > best,
> >
> > Forward
> >
> > 953396112 <953396...@qq.com> 于2020年4月29日周三 上午8:21写道：
> >
> > > Congrats, Jin Xing!
> > >
> > >
> > > ---Original---
> > > From: "Stamatis Zampetakis" > > Date: Wed, Apr 29, 2020 05:47 AM
> > > To: "dev" > > Subject: [ANNOUNCE] New committer: Jin Xing
> > >
> > >
> > > Apache Calcite's Project Management Committee (PMC) has invited Jin
> Xing
> > to
> > > become a committer, and we are pleased to announce that he has
> accepted.
> > >
> > > Jin has contributed a lot of code in the project and many
> > > recent improvements in
> > > materialized view matching have his signature on them. Apart from code
> > > contributions, Jin provides valuable help to the community by doing
> > reviews
> > > and
> > > answering questions in the devlist.
> > >
> > > Jin, welcome, thank you for your contributions, and we look forward to
> > your
> > > further interactions with the community! If you wish, please feel free
> to
> > > tell
> > > us more about yourself and what you are working on.
> > >
> > > Stamatis (on behalf of the Apache Calcite PMC)
> >
>

Re: [ANNOUNCE] New committer: Forward Xu

[Feng Zhu]

 Congrations! Forward!

best,
Feng

Chunwei Lei  于2020年4月29日周三 上午10:17写道：

> Congrats, Forward!
>
>
>
> Best,
> Chunwei
>
>
> On Wed, Apr 29, 2020 at 6:46 AM Rui Wang  wrote:
>
> > Congrats!
> >
> >
> > -Rui
> >
> > On Tue, Apr 28, 2020 at 3:04 PM Francis Chuang  >
> > wrote:
> >
> > > Congrats, Forward!
> > >
> > > Francis
> > >
> > > On 29/04/2020 7:53 am, Stamatis Zampetakis wrote:
> > > > Apache Calcite's Project Management Committee (PMC) has invited
> Forward
> > > Xu
> > > > to
> > > > become a committer, and we are pleased to announce that he has
> > accepted.
> > > >
> > > > Forward has been helping the project for some time now. He added many
> > new
> > > > SQL
> > > > functions to the project and is one of our JSON experts. On top of
> > that,
> > > and
> > > > other fixes, he is the one who added the Redis adapter to the
> project.
> > > >
> > > > Forward, welcome, thank you for your contributions, and we look
> forward
> > > to
> > > > your
> > > > further interactions with the community! If you wish, please feel
> free
> > to
> > > > tell
> > > > us more about yourself and what you are working on.
> > > >
> > > > Stamatis (on behalf of the Apache Calcite PMC)
> > > >
> > >
> >
>

Calcite-Master - Build # 1725 - Still Failing

[Apache Jenkins Server]

The Apache Jenkins build system has built Calcite-Master (build #1725)

Status: Still Failing

Check console output at https://builds.apache.org/job/Calcite-Master/1725/ to 
view the results.

Re: [ANNOUNCE] New committer: Jin Xing

[Enrico Olivelli]

Congratulations!

Enrico

Il Mer 29 Apr 2020, 04:51 Feng Zhu  ha scritto:

>  Congrations!
>
> best,
> Feng
>
> Chunwei Lei  于2020年4月29日周三 上午10:16写道：
>
> > Congrats, Jin!
> >
> >
> > Best,
> > Chunwei
> >
> >
> > On Wed, Apr 29, 2020 at 10:07 AM Forward Xu 
> > wrote:
> >
> > > Congrats
> > >
> > >
> > > best,
> > >
> > > Forward
> > >
> > > 953396112 <953396...@qq.com> 于2020年4月29日周三 上午8:21写道：
> > >
> > > > Congrats, Jin Xing!
> > > >
> > > >
> > > > ---Original---
> > > > From: "Stamatis Zampetakis" > > > Date: Wed, Apr 29, 2020 05:47 AM
> > > > To: "dev" > > > Subject: [ANNOUNCE] New committer: Jin Xing
> > > >
> > > >
> > > > Apache Calcite's Project Management Committee (PMC) has invited Jin
> > Xing
> > > to
> > > > become a committer, and we are pleased to announce that he has
> > accepted.
> > > >
> > > > Jin has contributed a lot of code in the project and many
> > > > recent improvements in
> > > > materialized view matching have his signature on them. Apart from
> code
> > > > contributions, Jin provides valuable help to the community by doing
> > > reviews
> > > > and
> > > > answering questions in the devlist.
> > > >
> > > > Jin, welcome, thank you for your contributions, and we look forward
> to
> > > your
> > > > further interactions with the community! If you wish, please feel
> free
> > to
> > > > tell
> > > > us more about yourself and what you are working on.
> > > >
> > > > Stamatis (on behalf of the Apache Calcite PMC)
> > >
> >
>

Re: [ANNOUNCE] New committer: Wang Yanlin

[Enrico Olivelli]

Congrats!

Enrico

Il Mer 29 Apr 2020, 04:51 Feng Zhu  ha scritto:

>  Congrations! Yanlin!
>
> best,
> Feng
>
> Chunwei Lei  于2020年4月29日周三 上午10:16写道：
>
> > Congrats, Yanlin!
> >
> >
> > Best,
> > Chunwei
> >
> >
> > On Wed, Apr 29, 2020 at 10:07 AM Forward Xu 
> > wrote:
> >
> > > Congrats
> > >
> > >
> > > Best,
> > >
> > > Forward
> > >
> > > 953396112 <953396...@qq.com> 于2020年4月29日周三 上午8:26写道：
> > >
> > > > Congrats, Wang Yanlin!
> > > >
> > > >
> > > >
> > > >
> > > > ---Original---
> > > > From: "Stamatis Zampetakis" > > > Date: Wed, Apr 29, 2020 05:51 AM
> > > > To: "dev" > > > Subject: [ANNOUNCE] New committer: Wang Yanlin
> > > >
> > > >
> > > > Apache Calcite's Project Management Committee (PMC) has invited Wang
> > > Yanlin
> > > > to
> > > > become a committer, and we are pleased to announce that he has
> > accepted.
> > > >
> > > > Wang has pushed numerous fixes and improvements to the project,
> landing
> > > in
> > > > total
> > > > the impressive number of 30 commits to the master. Among other
> things,
> > he
> > > > contributed some important features in the Interpreter.
> > > >
> > > > Wang, welcome, thank you for your contributions, and we look forward
> > your
> > > > further interactions with the community! If you wish, please feel
> free
> > to
> > > > tell
> > > > us more about yourself and what you are working on.
> > > >
> > > > Stamatis (on behalf of the Apache Calcite PMC)
> > >
> >
>

Re: [ANNOUNCE] New committer: Forward Xu

[Enrico Olivelli]

Congrats!

Enrico

Il Mer 29 Apr 2020, 04:52 Feng Zhu  ha scritto:

>  Congrations! Forward!
>
> best,
> Feng
>
> Chunwei Lei  于2020年4月29日周三 上午10:17写道：
>
> > Congrats, Forward!
> >
> >
> >
> > Best,
> > Chunwei
> >
> >
> > On Wed, Apr 29, 2020 at 6:46 AM Rui Wang  wrote:
> >
> > > Congrats!
> > >
> > >
> > > -Rui
> > >
> > > On Tue, Apr 28, 2020 at 3:04 PM Francis Chuang <
> francischu...@apache.org
> > >
> > > wrote:
> > >
> > > > Congrats, Forward!
> > > >
> > > > Francis
> > > >
> > > > On 29/04/2020 7:53 am, Stamatis Zampetakis wrote:
> > > > > Apache Calcite's Project Management Committee (PMC) has invited
> > Forward
> > > > Xu
> > > > > to
> > > > > become a committer, and we are pleased to announce that he has
> > > accepted.
> > > > >
> > > > > Forward has been helping the project for some time now. He added
> many
> > > new
> > > > > SQL
> > > > > functions to the project and is one of our JSON experts. On top of
> > > that,
> > > > and
> > > > > other fixes, he is the one who added the Redis adapter to the
> > project.
> > > > >
> > > > > Forward, welcome, thank you for your contributions, and we look
> > forward
> > > > to
> > > > > your
> > > > > further interactions with the community! If you wish, please feel
> > free
> > > to
> > > > > tell
> > > > > us more about yourself and what you are working on.
> > > > >
> > > > > Stamatis (on behalf of the Apache Calcite PMC)
> > > > >
> > > >
> > >
> >
>

Re: [ANNOUNCE] New committer: Wang Yanlin

[Zoltan Haindrich]

Congratulations!

On 4/29/20 7:32 AM, Enrico Olivelli wrote:

Congrats!

Enrico

Il Mer 29 Apr 2020, 04:51 Feng Zhu  ha scritto:


  Congrations! Yanlin!

best,
Feng

Chunwei Lei  于2020年4月29日周三 上午10:16写道：


Congrats, Yanlin!


Best,
Chunwei


On Wed, Apr 29, 2020 at 10:07 AM Forward Xu 
wrote:


Congrats


Best,

Forward

953396112 <953396...@qq.com> 于2020年4月29日周三 上午8:26写道：


Congrats, Wang Yanlin!




---Original---
From: "Stamatis Zampetakis"
Yanlin

to
become a committer, and we are pleased to announce that he has

accepted.


Wang has pushed numerous fixes and improvements to the project,

landing

in

total
the impressive number of 30 commits to the master. Among other

things,

he

contributed some important features in the Interpreter.

Wang, welcome, thank you for your contributions, and we look forward

your

further interactions with the community! If you wish, please feel

free

to

tell
us more about yourself and what you are working on.

Stamatis (on behalf of the Apache Calcite PMC)

Re: [ANNOUNCE] New committer: Jin Xing

[Zoltan Haindrich]

Congrats!

On 4/29/20 7:32 AM, Enrico Olivelli wrote:

Congratulations!

Enrico

Il Mer 29 Apr 2020, 04:51 Feng Zhu  ha scritto:


  Congrations!

best,
Feng

Chunwei Lei  于2020年4月29日周三 上午10:16写道：


Congrats, Jin!


Best,
Chunwei


On Wed, Apr 29, 2020 at 10:07 AM Forward Xu 
wrote:


Congrats


best,

Forward

953396112 <953396...@qq.com> 于2020年4月29日周三 上午8:21写道：


Congrats, Jin Xing!


---Original---
From: "Stamatis Zampetakis"
Xing

to

become a committer, and we are pleased to announce that he has

accepted.


Jin has contributed a lot of code in the project and many
recent improvements in
materialized view matching have his signature on them. Apart from

code

contributions, Jin provides valuable help to the community by doing

reviews

and
answering questions in the devlist.

Jin, welcome, thank you for your contributions, and we look forward

to

your

further interactions with the community! If you wish, please feel

free

to

tell
us more about yourself and what you are working on.

Stamatis (on behalf of the Apache Calcite PMC)

Re: [ANNOUNCE] New committer: Forward Xu

[Zoltan Haindrich]

Congratulations!

On 4/29/20 7:31 AM, Enrico Olivelli wrote:

Congrats!

Enrico

Il Mer 29 Apr 2020, 04:52 Feng Zhu  ha scritto:


  Congrations! Forward!

best,
Feng

Chunwei Lei  于2020年4月29日周三 上午10:17写道：


Congrats, Forward!



Best,
Chunwei


On Wed, Apr 29, 2020 at 6:46 AM Rui Wang  wrote:


Congrats!


-Rui

On Tue, Apr 28, 2020 at 3:04 PM Francis Chuang <

francischu...@apache.org


wrote:


Congrats, Forward!

Francis

On 29/04/2020 7:53 am, Stamatis Zampetakis wrote:

Apache Calcite's Project Management Committee (PMC) has invited

Forward

Xu

to
become a committer, and we are pleased to announce that he has

accepted.


Forward has been helping the project for some time now. He added

many

new

SQL
functions to the project and is one of our JSON experts. On top of

that,

and

other fixes, he is the one who added the Redis adapter to the

project.


Forward, welcome, thank you for your contributions, and we look

forward

to

your
further interactions with the community! If you wish, please feel

free

to

tell
us more about yourself and what you are working on.

Stamatis (on behalf of the Apache Calcite PMC)