Re: [ANNOUNCE] Danny Chan joins Calcite PMC

[Kurt Young]

Congratulations Danny!

Best,
Kurt


On Thu, Oct 31, 2019 at 11:18 AM Danny Chan  wrote:

> Thank you so much colleagues, it’s my honor to work with you!
>
> I have always felt respected and the harmony of the community, hope to
> contribute more and I would give help as best as I can, thanks !
>
> Best,
> Danny Chan
> 在 2019年10月31日 +0800 AM5:22，Francis Chuang ，写道：
> > I'm pleased to announce that Danny has accepted an invitation to
> > join the Calcite PMC. Danny has been a consistent and helpful
> > figure in the Calcite community for which we are very grateful. We
> > look forward to the continued contributions and support.
> >
> > Please join me in congratulating Danny!
> >
> > - Francis (on behalf of the Calcite PMC)
>

Re: [ANNOUNCE] Danny Chan joins Calcite PMC

[Danny Chan]

Thank you so much colleagues, it’s my honor to work with you!

I have always felt respected and the harmony of the community, hope to 
contribute more and I would give help as best as I can, thanks !

Best,
Danny Chan
在 2019年10月31日 +0800 AM5:22，Francis Chuang ，写道：
> I'm pleased to announce that Danny has accepted an invitation to
> join the Calcite PMC. Danny has been a consistent and helpful
> figure in the Calcite community for which we are very grateful. We
> look forward to the continued contributions and support.
>
> Please join me in congratulating Danny!
>
> - Francis (on behalf of the Calcite PMC)

Re: Re: [ANNOUNCE] Danny Chan joins Calcite PMC

[Meng Wang]

Congratulations Danny!


---
Best,
Matt Wang


Original Message
Sender:Chunwei leichunwei.l...@gmail.com
Recipient:dev...@calcite.apache.org
Date:Thursday, Oct 31, 2019 10:22
Subject:Re: Re: [ANNOUNCE] Danny Chan joins Calcite PMC


Congrats, Danny! Best, Chunwei On Thu, Oct 31, 2019 at 10:19 AM TANG Wen-hui  
winifred.wenhui.t...@gmail.com wrote:  Congratulations ! Danny 
winifred.wenhui.t...@gmail.com   From: Feng Zhu  Date: 2019-10-31 10:17  To: 
dev  Subject: Re: [ANNOUNCE] Danny Chan joins Calcite PMC  Congratulations ! 
Danny, thanks for your work!   XING JIN jinxing.co...@gmail.com 于2019年10月31日周四 
上午10:03写道：Congratulations ! Danny ~ OpenInx open...@gmail.com 
于2019年10月31日周四 上午9:33写道：  Congrats, Danny! Well deserve.   On Thu, Oct 
31, 2019 at 9:22 AM Leonard Xu xbjt...@gmail.com wrote:Congratulation！ 
Danny  On 2019年10月31日, at 上午9:06, Andrei Sereda and...@sereda.cc 
wrote:   Congrats, Danny!   On Wed, Oct 30, 2019 at 8:08 PM 
Julian Hyde jh...@apache.org   wrote:   Congratulations, Danny! Thank 
you for all of your hard work on  code,  reviewing others' work, answering 
questions, and generally making   our  community welcoming to all!  
 Julian   On Wed, Oct 30, 2019 at 4:32 PM Michael Mior mm...@apache.org 
   wrote:   Welcome on board Danny! Glad to have you.  --  
Michael Mior  mm...@apache.org   Le mer. 30 oct. 2019 à 17:22, 
Francis Chuang  francischu...@apache.org a écrit :   I'm pleased to 
announce that Danny has accepted an invitation to  join the Calcite PMC. 
Danny has been a consistent and helpful  figure in the Calcite community 
for which we are very grateful.  We  look forward to the continued 
contributions and support.   Please join me in congratulating Danny!
   - Francis (on behalf of the Calcite PMC)

Re: [ANNOUNCE] Danny Chan joins Calcite PMC

[Xiening Dai]

Congratulations, Danny! 


> On Oct 30, 2019, at 2:22 PM, Francis Chuang  wrote:
> 
> I'm pleased to announce that Danny has accepted an invitation to
> join the Calcite PMC. Danny has been a consistent and helpful
> figure in the Calcite community for which we are very grateful. We
> look forward to the continued contributions and support.
> 
> Please join me in congratulating Danny!
> 
> - Francis (on behalf of the Calcite PMC)

Re: Re: [ANNOUNCE] Danny Chan joins Calcite PMC

[Chunwei Lei]

Congrats, Danny!


Best,
Chunwei


On Thu, Oct 31, 2019 at 10:19 AM TANG Wen-hui <
winifred.wenhui.t...@gmail.com> wrote:

> Congratulations ! Danny
>
>
>
> winifred.wenhui.t...@gmail.com
>
> From: Feng Zhu
> Date: 2019-10-31 10:17
> To: dev
> Subject: Re: [ANNOUNCE] Danny Chan joins Calcite PMC
> Congratulations ! Danny, thanks for your work!
>
> XING JIN  于2019年10月31日周四 上午10:03写道：
>
> > Congratulations ! Danny ~
> >
> > OpenInx  于2019年10月31日周四 上午9:33写道：
> >
> > > Congrats, Danny!  Well deserve.
> > >
> > > On Thu, Oct 31, 2019 at 9:22 AM Leonard Xu  wrote:
> > >
> > > > Congratulation！ Danny
> > > >
> > > >
> > > > > On 2019年10月31日, at 上午9:06, Andrei Sereda  wrote:
> > > > >
> > > > > Congrats, Danny!
> > > > >
> > > > > On Wed, Oct 30, 2019 at 8:08 PM Julian Hyde 
> > wrote:
> > > > >
> > > > >> Congratulations, Danny! Thank you for all of your hard work on
> code,
> > > > >> reviewing others' work, answering questions, and generally making
> > our
> > > > >> community welcoming to all!
> > > > >>
> > > > >> Julian
> > > > >>
> > > > >> On Wed, Oct 30, 2019 at 4:32 PM Michael Mior 
> > > wrote:
> > > > >>>
> > > > >>> Welcome on board Danny! Glad to have you.
> > > > >>> --
> > > > >>> Michael Mior
> > > > >>> mm...@apache.org
> > > > >>>
> > > > >>> Le mer. 30 oct. 2019 à 17:22, Francis Chuang
> > > > >>>  a écrit :
> > > > 
> > > >  I'm pleased to announce that Danny has accepted an invitation to
> > > >  join the Calcite PMC. Danny has been a consistent and helpful
> > > >  figure in the Calcite community for which we are very grateful.
> We
> > > >  look forward to the continued contributions and support.
> > > > 
> > > >  Please join me in congratulating Danny!
> > > > 
> > > >  - Francis (on behalf of the Calcite PMC)
> > > > >>
> > > >
> > > >
> > >
> >
>

Re: Re: [ANNOUNCE] Danny Chan joins Calcite PMC

[TANG Wen-hui]

Congratulations ! Danny



winifred.wenhui.t...@gmail.com
 
From: Feng Zhu
Date: 2019-10-31 10:17
To: dev
Subject: Re: [ANNOUNCE] Danny Chan joins Calcite PMC
Congratulations ! Danny, thanks for your work!
 
XING JIN  于2019年10月31日周四 上午10:03写道：
 
> Congratulations ! Danny ~
>
> OpenInx  于2019年10月31日周四 上午9:33写道：
>
> > Congrats, Danny!  Well deserve.
> >
> > On Thu, Oct 31, 2019 at 9:22 AM Leonard Xu  wrote:
> >
> > > Congratulation！ Danny
> > >
> > >
> > > > On 2019年10月31日, at 上午9:06, Andrei Sereda  wrote:
> > > >
> > > > Congrats, Danny!
> > > >
> > > > On Wed, Oct 30, 2019 at 8:08 PM Julian Hyde 
> wrote:
> > > >
> > > >> Congratulations, Danny! Thank you for all of your hard work on code,
> > > >> reviewing others' work, answering questions, and generally making
> our
> > > >> community welcoming to all!
> > > >>
> > > >> Julian
> > > >>
> > > >> On Wed, Oct 30, 2019 at 4:32 PM Michael Mior 
> > wrote:
> > > >>>
> > > >>> Welcome on board Danny! Glad to have you.
> > > >>> --
> > > >>> Michael Mior
> > > >>> mm...@apache.org
> > > >>>
> > > >>> Le mer. 30 oct. 2019 à 17:22, Francis Chuang
> > > >>>  a écrit :
> > > 
> > >  I'm pleased to announce that Danny has accepted an invitation to
> > >  join the Calcite PMC. Danny has been a consistent and helpful
> > >  figure in the Calcite community for which we are very grateful. We
> > >  look forward to the continued contributions and support.
> > > 
> > >  Please join me in congratulating Danny!
> > > 
> > >  - Francis (on behalf of the Calcite PMC)
> > > >>
> > >
> > >
> >
>

Re: [ANNOUNCE] Danny Chan joins Calcite PMC

[Feng Zhu]

 Congratulations ! Danny, thanks for your work!

XING JIN  于2019年10月31日周四 上午10:03写道：

> Congratulations ! Danny ~
>
> OpenInx  于2019年10月31日周四 上午9:33写道：
>
> > Congrats, Danny!  Well deserve.
> >
> > On Thu, Oct 31, 2019 at 9:22 AM Leonard Xu  wrote:
> >
> > > Congratulation！ Danny
> > >
> > >
> > > > On 2019年10月31日, at 上午9:06, Andrei Sereda  wrote:
> > > >
> > > > Congrats, Danny!
> > > >
> > > > On Wed, Oct 30, 2019 at 8:08 PM Julian Hyde 
> wrote:
> > > >
> > > >> Congratulations, Danny! Thank you for all of your hard work on code,
> > > >> reviewing others' work, answering questions, and generally making
> our
> > > >> community welcoming to all!
> > > >>
> > > >> Julian
> > > >>
> > > >> On Wed, Oct 30, 2019 at 4:32 PM Michael Mior 
> > wrote:
> > > >>>
> > > >>> Welcome on board Danny! Glad to have you.
> > > >>> --
> > > >>> Michael Mior
> > > >>> mm...@apache.org
> > > >>>
> > > >>> Le mer. 30 oct. 2019 à 17:22, Francis Chuang
> > > >>>  a écrit :
> > > 
> > >  I'm pleased to announce that Danny has accepted an invitation to
> > >  join the Calcite PMC. Danny has been a consistent and helpful
> > >  figure in the Calcite community for which we are very grateful. We
> > >  look forward to the continued contributions and support.
> > > 
> > >  Please join me in congratulating Danny!
> > > 
> > >  - Francis (on behalf of the Calcite PMC)
> > > >>
> > >
> > >
> >
>

Re: [ANNOUNCE] Danny Chan joins Calcite PMC

[XING JIN]

Congratulations ! Danny ~

OpenInx  于2019年10月31日周四 上午9:33写道：

> Congrats, Danny!  Well deserve.
>
> On Thu, Oct 31, 2019 at 9:22 AM Leonard Xu  wrote:
>
> > Congratulation！ Danny
> >
> >
> > > On 2019年10月31日, at 上午9:06, Andrei Sereda  wrote:
> > >
> > > Congrats, Danny!
> > >
> > > On Wed, Oct 30, 2019 at 8:08 PM Julian Hyde  wrote:
> > >
> > >> Congratulations, Danny! Thank you for all of your hard work on code,
> > >> reviewing others' work, answering questions, and generally making our
> > >> community welcoming to all!
> > >>
> > >> Julian
> > >>
> > >> On Wed, Oct 30, 2019 at 4:32 PM Michael Mior 
> wrote:
> > >>>
> > >>> Welcome on board Danny! Glad to have you.
> > >>> --
> > >>> Michael Mior
> > >>> mm...@apache.org
> > >>>
> > >>> Le mer. 30 oct. 2019 à 17:22, Francis Chuang
> > >>>  a écrit :
> > 
> >  I'm pleased to announce that Danny has accepted an invitation to
> >  join the Calcite PMC. Danny has been a consistent and helpful
> >  figure in the Calcite community for which we are very grateful. We
> >  look forward to the continued contributions and support.
> > 
> >  Please join me in congratulating Danny!
> > 
> >  - Francis (on behalf of the Calcite PMC)
> > >>
> >
> >
>

Re: [ANNOUNCE] Danny Chan joins Calcite PMC

[OpenInx]

Congrats, Danny!  Well deserve.

On Thu, Oct 31, 2019 at 9:22 AM Leonard Xu  wrote:

> Congratulation！ Danny
>
>
> > On 2019年10月31日, at 上午9:06, Andrei Sereda  wrote:
> >
> > Congrats, Danny!
> >
> > On Wed, Oct 30, 2019 at 8:08 PM Julian Hyde  wrote:
> >
> >> Congratulations, Danny! Thank you for all of your hard work on code,
> >> reviewing others' work, answering questions, and generally making our
> >> community welcoming to all!
> >>
> >> Julian
> >>
> >> On Wed, Oct 30, 2019 at 4:32 PM Michael Mior  wrote:
> >>>
> >>> Welcome on board Danny! Glad to have you.
> >>> --
> >>> Michael Mior
> >>> mm...@apache.org
> >>>
> >>> Le mer. 30 oct. 2019 à 17:22, Francis Chuang
> >>>  a écrit :
> 
>  I'm pleased to announce that Danny has accepted an invitation to
>  join the Calcite PMC. Danny has been a consistent and helpful
>  figure in the Calcite community for which we are very grateful. We
>  look forward to the continued contributions and support.
> 
>  Please join me in congratulating Danny!
> 
>  - Francis (on behalf of the Calcite PMC)
> >>
>
>

Re: [ANNOUNCE] Danny Chan joins Calcite PMC

[Leonard Xu]

Congratulation！ Danny


> On 2019年10月31日, at 上午9:06, Andrei Sereda  wrote:
> 
> Congrats, Danny!
> 
> On Wed, Oct 30, 2019 at 8:08 PM Julian Hyde  wrote:
> 
>> Congratulations, Danny! Thank you for all of your hard work on code,
>> reviewing others' work, answering questions, and generally making our
>> community welcoming to all!
>> 
>> Julian
>> 
>> On Wed, Oct 30, 2019 at 4:32 PM Michael Mior  wrote:
>>> 
>>> Welcome on board Danny! Glad to have you.
>>> --
>>> Michael Mior
>>> mm...@apache.org
>>> 
>>> Le mer. 30 oct. 2019 à 17:22, Francis Chuang
>>>  a écrit :
 
 I'm pleased to announce that Danny has accepted an invitation to
 join the Calcite PMC. Danny has been a consistent and helpful
 figure in the Calcite community for which we are very grateful. We
 look forward to the continued contributions and support.
 
 Please join me in congratulating Danny!
 
 - Francis (on behalf of the Calcite PMC)
>> 

Re: [ANNOUNCE] Danny Chan joins Calcite PMC

[Andrei Sereda]

Congrats, Danny!

On Wed, Oct 30, 2019 at 8:08 PM Julian Hyde  wrote:

> Congratulations, Danny! Thank you for all of your hard work on code,
> reviewing others' work, answering questions, and generally making our
> community welcoming to all!
>
> Julian
>
> On Wed, Oct 30, 2019 at 4:32 PM Michael Mior  wrote:
> >
> > Welcome on board Danny! Glad to have you.
> > --
> > Michael Mior
> > mm...@apache.org
> >
> > Le mer. 30 oct. 2019 à 17:22, Francis Chuang
> >  a écrit :
> > >
> > > I'm pleased to announce that Danny has accepted an invitation to
> > > join the Calcite PMC. Danny has been a consistent and helpful
> > > figure in the Calcite community for which we are very grateful. We
> > > look forward to the continued contributions and support.
> > >
> > > Please join me in congratulating Danny!
> > >
> > > - Francis (on behalf of the Calcite PMC)
>

Re: [ANNOUNCE] Danny Chan joins Calcite PMC

[Julian Hyde]

Congratulations, Danny! Thank you for all of your hard work on code,
reviewing others' work, answering questions, and generally making our
community welcoming to all!

Julian

On Wed, Oct 30, 2019 at 4:32 PM Michael Mior  wrote:
>
> Welcome on board Danny! Glad to have you.
> --
> Michael Mior
> mm...@apache.org
>
> Le mer. 30 oct. 2019 à 17:22, Francis Chuang
>  a écrit :
> >
> > I'm pleased to announce that Danny has accepted an invitation to
> > join the Calcite PMC. Danny has been a consistent and helpful
> > figure in the Calcite community for which we are very grateful. We
> > look forward to the continued contributions and support.
> >
> > Please join me in congratulating Danny!
> >
> > - Francis (on behalf of the Calcite PMC)

Re: [ANNOUNCE] Danny Chan joins Calcite PMC

[Michael Mior]

Welcome on board Danny! Glad to have you.
--
Michael Mior
mm...@apache.org

Le mer. 30 oct. 2019 à 17:22, Francis Chuang
 a écrit :
>
> I'm pleased to announce that Danny has accepted an invitation to
> join the Calcite PMC. Danny has been a consistent and helpful
> figure in the Calcite community for which we are very grateful. We
> look forward to the continued contributions and support.
>
> Please join me in congratulating Danny!
>
> - Francis (on behalf of the Calcite PMC)

Re: Re: [ANNOUNCE] Danny Chan joins Calcite PMC

[Amit Chavan]

Congratulations, Danny !!

On Wed, Oct 30, 2019 at 3:14 PM Rui Wang  wrote:

> Congratulations! Well deserved!
>
>
> -Rui
>
> On Wed, Oct 30, 2019 at 3:04 PM Haisheng Yuan 
> wrote:
>
> > Congrats, Danny!
> >
> > - Haisheng
> >
> > --
> > 发件人：Peter Huang
> > 日 期：2019年10月31日 05:55:17
> > 收件人：
> > 主 题：Re: [ANNOUNCE] Danny Chan joins Calcite PMC
> >
> > Congratulations Danny!
> >
> > On Wed, Oct 30, 2019 at 2:22 PM Francis Chuang  >
> > wrote:
> >
> > > I'm pleased to announce that Danny has accepted an invitation to
> > > join the Calcite PMC. Danny has been a consistent and helpful
> > > figure in the Calcite community for which we are very grateful. We
> > > look forward to the continued contributions and support.
> > >
> > > Please join me in congratulating Danny!
> > >
> > > - Francis (on behalf of the Calcite PMC)
> > >
> >
> >
>

Re: Re: [ANNOUNCE] Danny Chan joins Calcite PMC

[Rui Wang]

Congratulations! Well deserved!


-Rui

On Wed, Oct 30, 2019 at 3:04 PM Haisheng Yuan 
wrote:

> Congrats, Danny!
>
> - Haisheng
>
> --
> 发件人：Peter Huang
> 日 期：2019年10月31日 05:55:17
> 收件人：
> 主 题：Re: [ANNOUNCE] Danny Chan joins Calcite PMC
>
> Congratulations Danny!
>
> On Wed, Oct 30, 2019 at 2:22 PM Francis Chuang 
> wrote:
>
> > I'm pleased to announce that Danny has accepted an invitation to
> > join the Calcite PMC. Danny has been a consistent and helpful
> > figure in the Calcite community for which we are very grateful. We
> > look forward to the continued contributions and support.
> >
> > Please join me in congratulating Danny!
> >
> > - Francis (on behalf of the Calcite PMC)
> >
>
>

Re: Re: [ANNOUNCE] Danny Chan joins Calcite PMC

[Haisheng Yuan]

Congrats, Danny!

- Haisheng

--
发件人：Peter Huang
日　期：2019年10月31日 05:55:17
收件人：
主　题：Re: [ANNOUNCE] Danny Chan joins Calcite PMC

Congratulations Danny!

On Wed, Oct 30, 2019 at 2:22 PM Francis Chuang 
wrote:

> I'm pleased to announce that Danny has accepted an invitation to
> join the Calcite PMC. Danny has been a consistent and helpful
> figure in the Calcite community for which we are very grateful. We
> look forward to the continued contributions and support.
>
> Please join me in congratulating Danny!
>
> - Francis (on behalf of the Calcite PMC)
>

Re: [ANNOUNCE] Danny Chan joins Calcite PMC

[Peter Huang]

Congratulations Danny!

On Wed, Oct 30, 2019 at 2:22 PM Francis Chuang 
wrote:

> I'm pleased to announce that Danny has accepted an invitation to
> join the Calcite PMC. Danny has been a consistent and helpful
> figure in the Calcite community for which we are very grateful. We
> look forward to the continued contributions and support.
>
> Please join me in congratulating Danny!
>
> - Francis (on behalf of the Calcite PMC)
>

[ANNOUNCE] Danny Chan joins Calcite PMC

[Francis Chuang]

I'm pleased to announce that Danny has accepted an invitation to
join the Calcite PMC. Danny has been a consistent and helpful
figure in the Calcite community for which we are very grateful. We
look forward to the continued contributions and support.

Please join me in congratulating Danny!

- Francis (on behalf of the Calcite PMC)

Re: Request for access to Jenkins job configuration

[Francis Chuang]

Hey Danny,

I've added you to the hudson-jobadmin group.

Francis

On 30/10/2019 10:04 pm, Danny Chan wrote:

Hello,

It seems that in order to view/edit the job configuration on Jenkins, someone 
needs to be in the hudson-jobadmin group [1].

@Francis: Would it be possible to add me (danny0405) to the group. It appears
that only PMC chairs can do that.

[1] https://whimsy.apache.org/roster/group/hudson-jobadmin

Best,
Danny Chan

Re: Snapshot jars

[Amit Chavan]

 I see the job succeeded and snapshots are now being published.
Thanks for a quick turnaround on this Kevin.

On Wed, Oct 30, 2019 at 11:23 AM Kevin Risden  wrote:

> Latest https://builds.apache.org/job/Calcite-Promotion/ run succeeded now
> and looks like
>
> https://repository.apache.org/content/repositories/snapshots/org/apache/calcite/
> has
> been updated for current modules.
>
> Kevin Risden
>
>
> On Wed, Oct 30, 2019 at 2:09 PM Kevin Risden  wrote:
>
> > Looked at the config for the job, looks like the Calcite-Master build
> uses
> > Maven (latest). Updated the Calcite-Promotion job to match and removed
> the
> > outdated JDK 7 description.
> >
> > Kicked off a rebuild last after the config change and it is making
> > progress:
> >
> > https://builds.apache.org/job/Calcite-Promotion/378/
> >
> > Kevin Risden
> >
> >
> > On Wed, Oct 30, 2019 at 2:04 PM Kevin Risden  wrote:
> >
> >> In theory https://builds.apache.org/job/Calcite-Promotion/ should be
> >> based on the description of the job "Promotes SNAPSHOT builds of Calcite
> >> to the ASF Nexus."
> >>
> >> It looks like it has been broken for a long time (last success was July
> >> 2019)?
> >>
> >> Kevin Risden
> >>
> >>
> >> On Wed, Oct 30, 2019 at 1:49 PM Amit Chavan  wrote:
> >>
> >>> Hello,
> >>>
> >>> I was wondering if the snapshot jars are being pushed to
> >>> https://repository.apache.org/content/repositories/snapshots
> >>> <
> >>>
> https://repository.apache.org/content/repositories/snapshots/org/apache/calcite/
> >>> >.
> >>> The reason I am asking is we are building herddb with the latest
> Calcite
> >>> master and want to test it against the snapshot builds of calcite so we
> >>> know bug fixes that are being put in place for Calcite are working.
> >>>
> >>> Thanks,
> >>> Amit
> >>>
> >>
>

Re: Snapshot jars

[Kevin Risden]

Latest https://builds.apache.org/job/Calcite-Promotion/ run succeeded now
and looks like
https://repository.apache.org/content/repositories/snapshots/org/apache/calcite/
has
been updated for current modules.

Kevin Risden


On Wed, Oct 30, 2019 at 2:09 PM Kevin Risden  wrote:

> Looked at the config for the job, looks like the Calcite-Master build uses
> Maven (latest). Updated the Calcite-Promotion job to match and removed the
> outdated JDK 7 description.
>
> Kicked off a rebuild last after the config change and it is making
> progress:
>
> https://builds.apache.org/job/Calcite-Promotion/378/
>
> Kevin Risden
>
>
> On Wed, Oct 30, 2019 at 2:04 PM Kevin Risden  wrote:
>
>> In theory https://builds.apache.org/job/Calcite-Promotion/ should be
>> based on the description of the job "Promotes SNAPSHOT builds of Calcite
>> to the ASF Nexus."
>>
>> It looks like it has been broken for a long time (last success was July
>> 2019)?
>>
>> Kevin Risden
>>
>>
>> On Wed, Oct 30, 2019 at 1:49 PM Amit Chavan  wrote:
>>
>>> Hello,
>>>
>>> I was wondering if the snapshot jars are being pushed to
>>> https://repository.apache.org/content/repositories/snapshots
>>> <
>>> https://repository.apache.org/content/repositories/snapshots/org/apache/calcite/
>>> >.
>>> The reason I am asking is we are building herddb with the latest Calcite
>>> master and want to test it against the snapshot builds of calcite so we
>>> know bug fixes that are being put in place for Calcite are working.
>>>
>>> Thanks,
>>> Amit
>>>
>>

Re: Problem with converters and possibly rule matching

[Vladimir Ozerov]

Hi Stamatis,

The problem that the presented reproducer is a very simplified version of
what is actually needed. In reality, there are several distribution types -
PARTITIONED, REPLICATED, SINGLETON. To make things worse, PARTITIONED may
or may not have concrete distribution fields. In theory, I can create one
transformation per distribution type, but that would increase plan space
significantly. In my sample "Root <- Project <- Scan" plan, there is no
room for optimization at all, we only need to convert the nodes and
propagate traits. But if I follow the proposed approach, the planner would
create three equivalent paths. For complex queries, this may increase
optimization time significantly.

What I need instead is to gradually convert and optimize nodes *bottom-up*,
instead of top-bottom. That is, create a physical scan first, then create a
physical project on top of it, etc. But at the same time, some rules still
require the top-bottom approach. So essentially I need the optimizer to do
both. Abstract converters help me establish bottom-up preparation but do
this at the cost of considering too many trait pairs, and as a result, also
pollute the search space.

To the contrast, precise command "I transformed the node A to node B,
please re-trigger the rules for A's parents" would allow us to re-trigger
only required rules, without adding more nodes.

Does it make sense?

Regards,
Vladimir.

ср, 30 окт. 2019 г. в 21:02, Stamatis Zampetakis :

> I admit that I didn't thoroughly read the exchanges so far but forcing the
> rules trigger does not seem the right approach.
>
> Other than that I would like to backtrack a bit to point 4.3 raised by
> Vladimir.
>
> "ProjectPhysicalRule [6] - transforms logical project to physical
> project *ONLY* if there is an underlying physical input with REPLICATED or
> SINGLETON distribution"
>
> The rule could be modified to do the following two transformations:
> 1. Create a physical project and require the input to be REPLICATED.
> 2. Create a physical project and require
> the input to be SINGLETON.
>
> I would assume that afterwards when your scan rule fires it should go to
> the appropriate subset and give you back the desired plan. Is there a
> problem with this approach?
>
> Best,
> Stamatis
>
> On Wed, Oct 30, 2019, 5:52 PM Seliverstov Igor 
> wrote:
>
> > Unfortunately it requires package-private API usage.
> >
> > Best solution there if Calcite provide it for end users.
> >
> > ср, 30 окт. 2019 г., 18:48 Vladimir Ozerov :
> >
> > > “e pension” == “expand conversion” :)
> > >
> > > ср, 30 окт. 2019 г. в 18:46, Vladimir Ozerov :
> > >
> > > > Yes, that may work. Even if e pension rule is used, for the most
> cases
> > it
> > > > will not trigger any real conversions, since we are moving from
> > abstract
> > > > convention to physical, and created converters will have the opposite
> > > trait
> > > > direction (from physical to abstract).
> > > >
> > > > But again - ideally we only need to re-trigger the rules for a
> specific
> > > > node, no more than that. So API support like
> > > > “VolcanoPlanner.forceRules(RelNode)” would be very convenient.
> > > >
> > > > What do you think?
> > > >
> > > > ср, 30 окт. 2019 г. в 17:56, Seliverstov Igor  >:
> > > >
> > > >> I considered manual rules calling too, for now we use abstract
> > > converters
> > > >> +
> > > >> ExpandConversionRule for exchanges producing.
> > > >>
> > > >> You may create such converters manually (checking appropriate
> subset)
> > > this
> > > >> case you may reduce created converters count, also, a converter is a
> > > quite
> > > >> special node, that does almost nothing (without corresponding rule)
> it
> > > may
> > > >> be used just as a rule trigger.
> > > >>
> > > >> Regards,
> > > >> Igor
> > > >>
> > > >> ср, 30 окт. 2019 г., 17:31 Vladimir Ozerov :
> > > >>
> > > >> > One funny hack which helped me is manual registration of a fake
> > > RelNode
> > > >> > with desired traits through VolcanoPlanner.register() method. But
> > > again,
> > > >> > this leads to trashing. What could really help is a call to
> > > >> > VolcanoPlanner.fireRules() with desired rel. But this doesn't work
> > out
> > > >> of
> > > >> > the box since some internals of the rule queue needs to be
> adjusted.
> > > >> >
> > > >> > What does the community think about adding a method which will
> > re-add
> > > >> rules
> > > >> > applicable to the specific RelNode to the rule queue?
> > > >> >
> > > >> > ср, 30 окт. 2019 г. в 17:00, Vladimir Ozerov  >:
> > > >> >
> > > >> > > Hi Igor,
> > > >> > >
> > > >> > > Yes, I came to the same conclusion, thank you. This is how it
> > > >> basically
> > > >> > > happens when converters are disabled:
> > > >> > > 1) We start with initial tree: [LogicalProject] <- [LogicalScan]
> > > >> > > 2) Then we convert LogicalScan to PhysicalScan, so it is added
> to
> > > the
> > > >> > > set: [LogicalProject] <- [LogicalScan, PhysicalScan]
> > > >> > > 3) Finally, when it is time to fire 

Re: Snapshot jars

[Kevin Risden]

Looked at the config for the job, looks like the Calcite-Master build uses
Maven (latest). Updated the Calcite-Promotion job to match and removed the
outdated JDK 7 description.

Kicked off a rebuild last after the config change and it is making progress:

https://builds.apache.org/job/Calcite-Promotion/378/

Kevin Risden


On Wed, Oct 30, 2019 at 2:04 PM Kevin Risden  wrote:

> In theory https://builds.apache.org/job/Calcite-Promotion/ should be
> based on the description of the job "Promotes SNAPSHOT builds of Calcite
> to the ASF Nexus."
>
> It looks like it has been broken for a long time (last success was July
> 2019)?
>
> Kevin Risden
>
>
> On Wed, Oct 30, 2019 at 1:49 PM Amit Chavan  wrote:
>
>> Hello,
>>
>> I was wondering if the snapshot jars are being pushed to
>> https://repository.apache.org/content/repositories/snapshots
>> <
>> https://repository.apache.org/content/repositories/snapshots/org/apache/calcite/
>> >.
>> The reason I am asking is we are building herddb with the latest Calcite
>> master and want to test it against the snapshot builds of calcite so we
>> know bug fixes that are being put in place for Calcite are working.
>>
>> Thanks,
>> Amit
>>
>

Re: Snapshot jars

[Kevin Risden]

In theory https://builds.apache.org/job/Calcite-Promotion/ should be based
on the description of the job "Promotes SNAPSHOT builds of Calcite to the
ASF Nexus."

It looks like it has been broken for a long time (last success was July
2019)?

Kevin Risden


On Wed, Oct 30, 2019 at 1:49 PM Amit Chavan  wrote:

> Hello,
>
> I was wondering if the snapshot jars are being pushed to
> https://repository.apache.org/content/repositories/snapshots
> <
> https://repository.apache.org/content/repositories/snapshots/org/apache/calcite/
> >.
> The reason I am asking is we are building herddb with the latest Calcite
> master and want to test it against the snapshot builds of calcite so we
> know bug fixes that are being put in place for Calcite are working.
>
> Thanks,
> Amit
>

Re: Problem with converters and possibly rule matching

[Stamatis Zampetakis]

I admit that I didn't thoroughly read the exchanges so far but forcing the
rules trigger does not seem the right approach.

Other than that I would like to backtrack a bit to point 4.3 raised by
Vladimir.

"ProjectPhysicalRule [6] - transforms logical project to physical
project *ONLY* if there is an underlying physical input with REPLICATED or
SINGLETON distribution"

The rule could be modified to do the following two transformations:
1. Create a physical project and require the input to be REPLICATED.
2. Create a physical project and require
the input to be SINGLETON.

I would assume that afterwards when your scan rule fires it should go to
the appropriate subset and give you back the desired plan. Is there a
problem with this approach?

Best,
Stamatis

On Wed, Oct 30, 2019, 5:52 PM Seliverstov Igor  wrote:

> Unfortunately it requires package-private API usage.
>
> Best solution there if Calcite provide it for end users.
>
> ср, 30 окт. 2019 г., 18:48 Vladimir Ozerov :
>
> > “e pension” == “expand conversion” :)
> >
> > ср, 30 окт. 2019 г. в 18:46, Vladimir Ozerov :
> >
> > > Yes, that may work. Even if e pension rule is used, for the most cases
> it
> > > will not trigger any real conversions, since we are moving from
> abstract
> > > convention to physical, and created converters will have the opposite
> > trait
> > > direction (from physical to abstract).
> > >
> > > But again - ideally we only need to re-trigger the rules for a specific
> > > node, no more than that. So API support like
> > > “VolcanoPlanner.forceRules(RelNode)” would be very convenient.
> > >
> > > What do you think?
> > >
> > > ср, 30 окт. 2019 г. в 17:56, Seliverstov Igor :
> > >
> > >> I considered manual rules calling too, for now we use abstract
> > converters
> > >> +
> > >> ExpandConversionRule for exchanges producing.
> > >>
> > >> You may create such converters manually (checking appropriate subset)
> > this
> > >> case you may reduce created converters count, also, a converter is a
> > quite
> > >> special node, that does almost nothing (without corresponding rule) it
> > may
> > >> be used just as a rule trigger.
> > >>
> > >> Regards,
> > >> Igor
> > >>
> > >> ср, 30 окт. 2019 г., 17:31 Vladimir Ozerov :
> > >>
> > >> > One funny hack which helped me is manual registration of a fake
> > RelNode
> > >> > with desired traits through VolcanoPlanner.register() method. But
> > again,
> > >> > this leads to trashing. What could really help is a call to
> > >> > VolcanoPlanner.fireRules() with desired rel. But this doesn't work
> out
> > >> of
> > >> > the box since some internals of the rule queue needs to be adjusted.
> > >> >
> > >> > What does the community think about adding a method which will
> re-add
> > >> rules
> > >> > applicable to the specific RelNode to the rule queue?
> > >> >
> > >> > ср, 30 окт. 2019 г. в 17:00, Vladimir Ozerov :
> > >> >
> > >> > > Hi Igor,
> > >> > >
> > >> > > Yes, I came to the same conclusion, thank you. This is how it
> > >> basically
> > >> > > happens when converters are disabled:
> > >> > > 1) We start with initial tree: [LogicalProject] <- [LogicalScan]
> > >> > > 2) Then we convert LogicalScan to PhysicalScan, so it is added to
> > the
> > >> > > set: [LogicalProject] <- [LogicalScan, PhysicalScan]
> > >> > > 3) Finally, when it is time to fire a rule for PhysicalScan, we
> try
> > to
> > >> > get
> > >> > > parents of that scan set with traits of the PhysicalScan. Since
> > there
> > >> are
> > >> > > no such parents (we skipped it intentionally), the rule is not
> > queued.
> > >> > >
> > >> > > But when converters are enabled, a converter rel is created:
> > >> > [LogicalProject]
> > >> > > <- [LogicalScan, PhysicalScan, ConverterFromPhysicalToLogical]. No
> > >> rules
> > >> > > are fired for PhysicalScan again, but they are fired for converter
> > >> since
> > >> > > it has the necessary LOGICAL trait.
> > >> > >
> > >> > > It makes sense, that converters essentially allow forcing rule
> > >> invocation
> > >> > > on parents, even if the child was created with different traits.
> But
> > >> it
> > >> > > seems that this mechanism may be too heavy for complex queries
> > >> because it
> > >> > > literally creates hundreds of new converter rels and triggers
> rules
> > >> over
> > >> > > and over again.
> > >> > >
> > >> > > We need some fine-grained alternative. Basically, what would be
> > enough
> > >> > for
> > >> > > me is to let the planner know somehow: "I created that rel, and I
> > want
> > >> > you
> > >> > > to execute parent rules not only using its trait but also on this
> > and
> > >> > those
> > >> > > traits."
> > >> > > Is there any API in Calcite which allows doing this without
> > creating a
> > >> > new
> > >> > > rel node?
> > >> > >
> > >> > > Regards,
> > >> > > Vladimir.
> > >> > >
> > >> > >
> > >> > > ср, 30 окт. 2019 г. в 09:25, Seliverstov Igor <
> gvvinbl...@gmail.com
> > >:
> > >> > >
> > >> > >> Vladimir,
> > >> > >>
> > >> > >> Probably it'll help 

Snapshot jars

[Amit Chavan]

Hello,

I was wondering if the snapshot jars are being pushed to
https://repository.apache.org/content/repositories/snapshots
.
The reason I am asking is we are building herddb with the latest Calcite
master and want to test it against the snapshot builds of calcite so we
know bug fixes that are being put in place for Calcite are working.

Thanks,
Amit

Re: Problem with converters and possibly rule matching

[Seliverstov Igor]

Unfortunately it requires package-private API usage.

Best solution there if Calcite provide it for end users.

ср, 30 окт. 2019 г., 18:48 Vladimir Ozerov :

> “e pension” == “expand conversion” :)
>
> ср, 30 окт. 2019 г. в 18:46, Vladimir Ozerov :
>
> > Yes, that may work. Even if e pension rule is used, for the most cases it
> > will not trigger any real conversions, since we are moving from abstract
> > convention to physical, and created converters will have the opposite
> trait
> > direction (from physical to abstract).
> >
> > But again - ideally we only need to re-trigger the rules for a specific
> > node, no more than that. So API support like
> > “VolcanoPlanner.forceRules(RelNode)” would be very convenient.
> >
> > What do you think?
> >
> > ср, 30 окт. 2019 г. в 17:56, Seliverstov Igor :
> >
> >> I considered manual rules calling too, for now we use abstract
> converters
> >> +
> >> ExpandConversionRule for exchanges producing.
> >>
> >> You may create such converters manually (checking appropriate subset)
> this
> >> case you may reduce created converters count, also, a converter is a
> quite
> >> special node, that does almost nothing (without corresponding rule) it
> may
> >> be used just as a rule trigger.
> >>
> >> Regards,
> >> Igor
> >>
> >> ср, 30 окт. 2019 г., 17:31 Vladimir Ozerov :
> >>
> >> > One funny hack which helped me is manual registration of a fake
> RelNode
> >> > with desired traits through VolcanoPlanner.register() method. But
> again,
> >> > this leads to trashing. What could really help is a call to
> >> > VolcanoPlanner.fireRules() with desired rel. But this doesn't work out
> >> of
> >> > the box since some internals of the rule queue needs to be adjusted.
> >> >
> >> > What does the community think about adding a method which will re-add
> >> rules
> >> > applicable to the specific RelNode to the rule queue?
> >> >
> >> > ср, 30 окт. 2019 г. в 17:00, Vladimir Ozerov :
> >> >
> >> > > Hi Igor,
> >> > >
> >> > > Yes, I came to the same conclusion, thank you. This is how it
> >> basically
> >> > > happens when converters are disabled:
> >> > > 1) We start with initial tree: [LogicalProject] <- [LogicalScan]
> >> > > 2) Then we convert LogicalScan to PhysicalScan, so it is added to
> the
> >> > > set: [LogicalProject] <- [LogicalScan, PhysicalScan]
> >> > > 3) Finally, when it is time to fire a rule for PhysicalScan, we try
> to
> >> > get
> >> > > parents of that scan set with traits of the PhysicalScan. Since
> there
> >> are
> >> > > no such parents (we skipped it intentionally), the rule is not
> queued.
> >> > >
> >> > > But when converters are enabled, a converter rel is created:
> >> > [LogicalProject]
> >> > > <- [LogicalScan, PhysicalScan, ConverterFromPhysicalToLogical]. No
> >> rules
> >> > > are fired for PhysicalScan again, but they are fired for converter
> >> since
> >> > > it has the necessary LOGICAL trait.
> >> > >
> >> > > It makes sense, that converters essentially allow forcing rule
> >> invocation
> >> > > on parents, even if the child was created with different traits. But
> >> it
> >> > > seems that this mechanism may be too heavy for complex queries
> >> because it
> >> > > literally creates hundreds of new converter rels and triggers rules
> >> over
> >> > > and over again.
> >> > >
> >> > > We need some fine-grained alternative. Basically, what would be
> enough
> >> > for
> >> > > me is to let the planner know somehow: "I created that rel, and I
> want
> >> > you
> >> > > to execute parent rules not only using its trait but also on this
> and
> >> > those
> >> > > traits."
> >> > > Is there any API in Calcite which allows doing this without
> creating a
> >> > new
> >> > > rel node?
> >> > >
> >> > > Regards,
> >> > > Vladimir.
> >> > >
> >> > >
> >> > > ср, 30 окт. 2019 г. в 09:25, Seliverstov Igor  >:
> >> > >
> >> > >> Vladimir,
> >> > >>
> >> > >> Probably it'll help you:
> >> > >>
> >> > >> Seems the cause of issue in RelSubset.getParentRels()  The check
> used
> >> > when
> >> > >> the planner schedules newly matched rules after successful
> >> > transformation
> >> > >> (see VolcanoRuleCall.matchRecurse), it prevents the parent rule be
> >> > applied
> >> > >> once again (here your logical project with an input having ANY
> >> > >> distribution
> >> > >> doesn't satisfy a transformed input traits).
> >> > >>
> >> > >> In our case we use another workaround, so there are also much more
> >> > >> transformations than we wanted, so the desired rule is triggered.
> >> > >>
> >> > >>
> >> > >> вт, 29 окт. 2019 г., 14:46 Vladimir Ozerov :
> >> > >>
> >> > >> > Hi Vladimir,
> >> > >> >
> >> > >> > I am sorry. Pushed, it works now.
> >> > >> >
> >> > >> > вт, 29 окт. 2019 г. в 14:41, Vladimir Sitnikov <
> >> > >> > sitnikov.vladi...@gmail.com
> >> > >> > >:
> >> > >> >
> >> > >> > > > mvn clean test
> >> > >> > >
> >> > >> > > [ERROR] The goal you specified requires a project to execute
> but
> >> > >> there is
> >> > >> > > no POM in this 

[jira] [Created] (CALCITE-3462) Add method in RelBuilder for conveniently projecting out expressions

[Stamatis Zampetakis (Jira)]

Stamatis Zampetakis created CALCITE-3462:


 Summary: Add method in RelBuilder for conveniently projecting out 
expressions
 Key: CALCITE-3462
 URL: https://issues.apache.org/jira/browse/CALCITE-3462
 Project: Calcite
  Issue Type: Improvement
  Components: core
Affects Versions: 1.21.0
Reporter: Stamatis Zampetakis
Assignee: Stamatis Zampetakis
 Fix For: 1.22.0


Add a new method in RelBuilder (i.e., {{RelBuilder.projectMinus}}) to 
facilitate the task of projecting out certain expressions from the top of the 
plan. 

The proposed method is purely for convenience and is the dual of the existing 
{{RelBuilder.projectPlus}}.





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

Re: Problem with converters and possibly rule matching

[Vladimir Ozerov]

Yes, that may work. Even if e pension rule is used, for the most cases it
will not trigger any real conversions, since we are moving from abstract
convention to physical, and created converters will have the opposite trait
direction (from physical to abstract).

But again - ideally we only need to re-trigger the rules for a specific
node, no more than that. So API support like
“VolcanoPlanner.forceRules(RelNode)” would be very convenient.

What do you think?

ср, 30 окт. 2019 г. в 17:56, Seliverstov Igor :

> I considered manual rules calling too, for now we use abstract converters +
> ExpandConversionRule for exchanges producing.
>
> You may create such converters manually (checking appropriate subset) this
> case you may reduce created converters count, also, a converter is a quite
> special node, that does almost nothing (without corresponding rule) it may
> be used just as a rule trigger.
>
> Regards,
> Igor
>
> ср, 30 окт. 2019 г., 17:31 Vladimir Ozerov :
>
> > One funny hack which helped me is manual registration of a fake RelNode
> > with desired traits through VolcanoPlanner.register() method. But again,
> > this leads to trashing. What could really help is a call to
> > VolcanoPlanner.fireRules() with desired rel. But this doesn't work out of
> > the box since some internals of the rule queue needs to be adjusted.
> >
> > What does the community think about adding a method which will re-add
> rules
> > applicable to the specific RelNode to the rule queue?
> >
> > ср, 30 окт. 2019 г. в 17:00, Vladimir Ozerov :
> >
> > > Hi Igor,
> > >
> > > Yes, I came to the same conclusion, thank you. This is how it basically
> > > happens when converters are disabled:
> > > 1) We start with initial tree: [LogicalProject] <- [LogicalScan]
> > > 2) Then we convert LogicalScan to PhysicalScan, so it is added to the
> > > set: [LogicalProject] <- [LogicalScan, PhysicalScan]
> > > 3) Finally, when it is time to fire a rule for PhysicalScan, we try to
> > get
> > > parents of that scan set with traits of the PhysicalScan. Since there
> are
> > > no such parents (we skipped it intentionally), the rule is not queued.
> > >
> > > But when converters are enabled, a converter rel is created:
> > [LogicalProject]
> > > <- [LogicalScan, PhysicalScan, ConverterFromPhysicalToLogical]. No
> rules
> > > are fired for PhysicalScan again, but they are fired for converter
> since
> > > it has the necessary LOGICAL trait.
> > >
> > > It makes sense, that converters essentially allow forcing rule
> invocation
> > > on parents, even if the child was created with different traits. But it
> > > seems that this mechanism may be too heavy for complex queries because
> it
> > > literally creates hundreds of new converter rels and triggers rules
> over
> > > and over again.
> > >
> > > We need some fine-grained alternative. Basically, what would be enough
> > for
> > > me is to let the planner know somehow: "I created that rel, and I want
> > you
> > > to execute parent rules not only using its trait but also on this and
> > those
> > > traits."
> > > Is there any API in Calcite which allows doing this without creating a
> > new
> > > rel node?
> > >
> > > Regards,
> > > Vladimir.
> > >
> > >
> > > ср, 30 окт. 2019 г. в 09:25, Seliverstov Igor :
> > >
> > >> Vladimir,
> > >>
> > >> Probably it'll help you:
> > >>
> > >> Seems the cause of issue in RelSubset.getParentRels()  The check used
> > when
> > >> the planner schedules newly matched rules after successful
> > transformation
> > >> (see VolcanoRuleCall.matchRecurse), it prevents the parent rule be
> > applied
> > >> once again (here your logical project with an input having ANY
> > >> distribution
> > >> doesn't satisfy a transformed input traits).
> > >>
> > >> In our case we use another workaround, so there are also much more
> > >> transformations than we wanted, so the desired rule is triggered.
> > >>
> > >>
> > >> вт, 29 окт. 2019 г., 14:46 Vladimir Ozerov :
> > >>
> > >> > Hi Vladimir,
> > >> >
> > >> > I am sorry. Pushed, it works now.
> > >> >
> > >> > вт, 29 окт. 2019 г. в 14:41, Vladimir Sitnikov <
> > >> > sitnikov.vladi...@gmail.com
> > >> > >:
> > >> >
> > >> > > > mvn clean test
> > >> > >
> > >> > > [ERROR] The goal you specified requires a project to execute but
> > >> there is
> > >> > > no POM in this directory
> > >> > >
> > >> > > Vladimir, please push missing files
> > >> > >
> > >> > > Vladimir
> > >> > >
> > >> >
> > >>
> > >
> >
>

Re: Problem with converters and possibly rule matching

[Vladimir Ozerov]

“e pension” == “expand conversion” :)

ср, 30 окт. 2019 г. в 18:46, Vladimir Ozerov :

> Yes, that may work. Even if e pension rule is used, for the most cases it
> will not trigger any real conversions, since we are moving from abstract
> convention to physical, and created converters will have the opposite trait
> direction (from physical to abstract).
>
> But again - ideally we only need to re-trigger the rules for a specific
> node, no more than that. So API support like
> “VolcanoPlanner.forceRules(RelNode)” would be very convenient.
>
> What do you think?
>
> ср, 30 окт. 2019 г. в 17:56, Seliverstov Igor :
>
>> I considered manual rules calling too, for now we use abstract converters
>> +
>> ExpandConversionRule for exchanges producing.
>>
>> You may create such converters manually (checking appropriate subset) this
>> case you may reduce created converters count, also, a converter is a quite
>> special node, that does almost nothing (without corresponding rule) it may
>> be used just as a rule trigger.
>>
>> Regards,
>> Igor
>>
>> ср, 30 окт. 2019 г., 17:31 Vladimir Ozerov :
>>
>> > One funny hack which helped me is manual registration of a fake RelNode
>> > with desired traits through VolcanoPlanner.register() method. But again,
>> > this leads to trashing. What could really help is a call to
>> > VolcanoPlanner.fireRules() with desired rel. But this doesn't work out
>> of
>> > the box since some internals of the rule queue needs to be adjusted.
>> >
>> > What does the community think about adding a method which will re-add
>> rules
>> > applicable to the specific RelNode to the rule queue?
>> >
>> > ср, 30 окт. 2019 г. в 17:00, Vladimir Ozerov :
>> >
>> > > Hi Igor,
>> > >
>> > > Yes, I came to the same conclusion, thank you. This is how it
>> basically
>> > > happens when converters are disabled:
>> > > 1) We start with initial tree: [LogicalProject] <- [LogicalScan]
>> > > 2) Then we convert LogicalScan to PhysicalScan, so it is added to the
>> > > set: [LogicalProject] <- [LogicalScan, PhysicalScan]
>> > > 3) Finally, when it is time to fire a rule for PhysicalScan, we try to
>> > get
>> > > parents of that scan set with traits of the PhysicalScan. Since there
>> are
>> > > no such parents (we skipped it intentionally), the rule is not queued.
>> > >
>> > > But when converters are enabled, a converter rel is created:
>> > [LogicalProject]
>> > > <- [LogicalScan, PhysicalScan, ConverterFromPhysicalToLogical]. No
>> rules
>> > > are fired for PhysicalScan again, but they are fired for converter
>> since
>> > > it has the necessary LOGICAL trait.
>> > >
>> > > It makes sense, that converters essentially allow forcing rule
>> invocation
>> > > on parents, even if the child was created with different traits. But
>> it
>> > > seems that this mechanism may be too heavy for complex queries
>> because it
>> > > literally creates hundreds of new converter rels and triggers rules
>> over
>> > > and over again.
>> > >
>> > > We need some fine-grained alternative. Basically, what would be enough
>> > for
>> > > me is to let the planner know somehow: "I created that rel, and I want
>> > you
>> > > to execute parent rules not only using its trait but also on this and
>> > those
>> > > traits."
>> > > Is there any API in Calcite which allows doing this without creating a
>> > new
>> > > rel node?
>> > >
>> > > Regards,
>> > > Vladimir.
>> > >
>> > >
>> > > ср, 30 окт. 2019 г. в 09:25, Seliverstov Igor :
>> > >
>> > >> Vladimir,
>> > >>
>> > >> Probably it'll help you:
>> > >>
>> > >> Seems the cause of issue in RelSubset.getParentRels()  The check used
>> > when
>> > >> the planner schedules newly matched rules after successful
>> > transformation
>> > >> (see VolcanoRuleCall.matchRecurse), it prevents the parent rule be
>> > applied
>> > >> once again (here your logical project with an input having ANY
>> > >> distribution
>> > >> doesn't satisfy a transformed input traits).
>> > >>
>> > >> In our case we use another workaround, so there are also much more
>> > >> transformations than we wanted, so the desired rule is triggered.
>> > >>
>> > >>
>> > >> вт, 29 окт. 2019 г., 14:46 Vladimir Ozerov :
>> > >>
>> > >> > Hi Vladimir,
>> > >> >
>> > >> > I am sorry. Pushed, it works now.
>> > >> >
>> > >> > вт, 29 окт. 2019 г. в 14:41, Vladimir Sitnikov <
>> > >> > sitnikov.vladi...@gmail.com
>> > >> > >:
>> > >> >
>> > >> > > > mvn clean test
>> > >> > >
>> > >> > > [ERROR] The goal you specified requires a project to execute but
>> > >> there is
>> > >> > > no POM in this directory
>> > >> > >
>> > >> > > Vladimir, please push missing files
>> > >> > >
>> > >> > > Vladimir
>> > >> > >
>> > >> >
>> > >>
>> > >
>> >
>>
>

1

[953396112]

1

Re: Problem with converters and possibly rule matching

[Seliverstov Igor]

I considered manual rules calling too, for now we use abstract converters +
ExpandConversionRule for exchanges producing.

You may create such converters manually (checking appropriate subset) this
case you may reduce created converters count, also, a converter is a quite
special node, that does almost nothing (without corresponding rule) it may
be used just as a rule trigger.

Regards,
Igor

ср, 30 окт. 2019 г., 17:31 Vladimir Ozerov :

> One funny hack which helped me is manual registration of a fake RelNode
> with desired traits through VolcanoPlanner.register() method. But again,
> this leads to trashing. What could really help is a call to
> VolcanoPlanner.fireRules() with desired rel. But this doesn't work out of
> the box since some internals of the rule queue needs to be adjusted.
>
> What does the community think about adding a method which will re-add rules
> applicable to the specific RelNode to the rule queue?
>
> ср, 30 окт. 2019 г. в 17:00, Vladimir Ozerov :
>
> > Hi Igor,
> >
> > Yes, I came to the same conclusion, thank you. This is how it basically
> > happens when converters are disabled:
> > 1) We start with initial tree: [LogicalProject] <- [LogicalScan]
> > 2) Then we convert LogicalScan to PhysicalScan, so it is added to the
> > set: [LogicalProject] <- [LogicalScan, PhysicalScan]
> > 3) Finally, when it is time to fire a rule for PhysicalScan, we try to
> get
> > parents of that scan set with traits of the PhysicalScan. Since there are
> > no such parents (we skipped it intentionally), the rule is not queued.
> >
> > But when converters are enabled, a converter rel is created:
> [LogicalProject]
> > <- [LogicalScan, PhysicalScan, ConverterFromPhysicalToLogical]. No rules
> > are fired for PhysicalScan again, but they are fired for converter since
> > it has the necessary LOGICAL trait.
> >
> > It makes sense, that converters essentially allow forcing rule invocation
> > on parents, even if the child was created with different traits. But it
> > seems that this mechanism may be too heavy for complex queries because it
> > literally creates hundreds of new converter rels and triggers rules over
> > and over again.
> >
> > We need some fine-grained alternative. Basically, what would be enough
> for
> > me is to let the planner know somehow: "I created that rel, and I want
> you
> > to execute parent rules not only using its trait but also on this and
> those
> > traits."
> > Is there any API in Calcite which allows doing this without creating a
> new
> > rel node?
> >
> > Regards,
> > Vladimir.
> >
> >
> > ср, 30 окт. 2019 г. в 09:25, Seliverstov Igor :
> >
> >> Vladimir,
> >>
> >> Probably it'll help you:
> >>
> >> Seems the cause of issue in RelSubset.getParentRels()  The check used
> when
> >> the planner schedules newly matched rules after successful
> transformation
> >> (see VolcanoRuleCall.matchRecurse), it prevents the parent rule be
> applied
> >> once again (here your logical project with an input having ANY
> >> distribution
> >> doesn't satisfy a transformed input traits).
> >>
> >> In our case we use another workaround, so there are also much more
> >> transformations than we wanted, so the desired rule is triggered.
> >>
> >>
> >> вт, 29 окт. 2019 г., 14:46 Vladimir Ozerov :
> >>
> >> > Hi Vladimir,
> >> >
> >> > I am sorry. Pushed, it works now.
> >> >
> >> > вт, 29 окт. 2019 г. в 14:41, Vladimir Sitnikov <
> >> > sitnikov.vladi...@gmail.com
> >> > >:
> >> >
> >> > > > mvn clean test
> >> > >
> >> > > [ERROR] The goal you specified requires a project to execute but
> >> there is
> >> > > no POM in this directory
> >> > >
> >> > > Vladimir, please push missing files
> >> > >
> >> > > Vladimir
> >> > >
> >> >
> >>
> >
>

Re: Problem with converters and possibly rule matching

[Vladimir Ozerov]

One funny hack which helped me is manual registration of a fake RelNode
with desired traits through VolcanoPlanner.register() method. But again,
this leads to trashing. What could really help is a call to
VolcanoPlanner.fireRules() with desired rel. But this doesn't work out of
the box since some internals of the rule queue needs to be adjusted.

What does the community think about adding a method which will re-add rules
applicable to the specific RelNode to the rule queue?

ср, 30 окт. 2019 г. в 17:00, Vladimir Ozerov :

> Hi Igor,
>
> Yes, I came to the same conclusion, thank you. This is how it basically
> happens when converters are disabled:
> 1) We start with initial tree: [LogicalProject] <- [LogicalScan]
> 2) Then we convert LogicalScan to PhysicalScan, so it is added to the
> set: [LogicalProject] <- [LogicalScan, PhysicalScan]
> 3) Finally, when it is time to fire a rule for PhysicalScan, we try to get
> parents of that scan set with traits of the PhysicalScan. Since there are
> no such parents (we skipped it intentionally), the rule is not queued.
>
> But when converters are enabled, a converter rel is created: [LogicalProject]
> <- [LogicalScan, PhysicalScan, ConverterFromPhysicalToLogical]. No rules
> are fired for PhysicalScan again, but they are fired for converter since
> it has the necessary LOGICAL trait.
>
> It makes sense, that converters essentially allow forcing rule invocation
> on parents, even if the child was created with different traits. But it
> seems that this mechanism may be too heavy for complex queries because it
> literally creates hundreds of new converter rels and triggers rules over
> and over again.
>
> We need some fine-grained alternative. Basically, what would be enough for
> me is to let the planner know somehow: "I created that rel, and I want you
> to execute parent rules not only using its trait but also on this and those
> traits."
> Is there any API in Calcite which allows doing this without creating a new
> rel node?
>
> Regards,
> Vladimir.
>
>
> ср, 30 окт. 2019 г. в 09:25, Seliverstov Igor :
>
>> Vladimir,
>>
>> Probably it'll help you:
>>
>> Seems the cause of issue in RelSubset.getParentRels()  The check used when
>> the planner schedules newly matched rules after successful transformation
>> (see VolcanoRuleCall.matchRecurse), it prevents the parent rule be applied
>> once again (here your logical project with an input having ANY
>> distribution
>> doesn't satisfy a transformed input traits).
>>
>> In our case we use another workaround, so there are also much more
>> transformations than we wanted, so the desired rule is triggered.
>>
>>
>> вт, 29 окт. 2019 г., 14:46 Vladimir Ozerov :
>>
>> > Hi Vladimir,
>> >
>> > I am sorry. Pushed, it works now.
>> >
>> > вт, 29 окт. 2019 г. в 14:41, Vladimir Sitnikov <
>> > sitnikov.vladi...@gmail.com
>> > >:
>> >
>> > > > mvn clean test
>> > >
>> > > [ERROR] The goal you specified requires a project to execute but
>> there is
>> > > no POM in this directory
>> > >
>> > > Vladimir, please push missing files
>> > >
>> > > Vladimir
>> > >
>> >
>>
>

Re: Problem with converters and possibly rule matching

[Vladimir Ozerov]

Hi Igor,

Yes, I came to the same conclusion, thank you. This is how it basically
happens when converters are disabled:
1) We start with initial tree: [LogicalProject] <- [LogicalScan]
2) Then we convert LogicalScan to PhysicalScan, so it is added to the
set: [LogicalProject]
<- [LogicalScan, PhysicalScan]
3) Finally, when it is time to fire a rule for PhysicalScan, we try to get
parents of that scan set with traits of the PhysicalScan. Since there are
no such parents (we skipped it intentionally), the rule is not queued.

But when converters are enabled, a converter rel is created: [LogicalProject]
<- [LogicalScan, PhysicalScan, ConverterFromPhysicalToLogical]. No rules
are fired for PhysicalScan again, but they are fired for converter since it
has the necessary LOGICAL trait.

It makes sense, that converters essentially allow forcing rule invocation
on parents, even if the child was created with different traits. But it
seems that this mechanism may be too heavy for complex queries because it
literally creates hundreds of new converter rels and triggers rules over
and over again.

We need some fine-grained alternative. Basically, what would be enough for
me is to let the planner know somehow: "I created that rel, and I want you
to execute parent rules not only using its trait but also on this and those
traits."
Is there any API in Calcite which allows doing this without creating a new
rel node?

Regards,
Vladimir.


ср, 30 окт. 2019 г. в 09:25, Seliverstov Igor :

> Vladimir,
>
> Probably it'll help you:
>
> Seems the cause of issue in RelSubset.getParentRels()  The check used when
> the planner schedules newly matched rules after successful transformation
> (see VolcanoRuleCall.matchRecurse), it prevents the parent rule be applied
> once again (here your logical project with an input having ANY distribution
> doesn't satisfy a transformed input traits).
>
> In our case we use another workaround, so there are also much more
> transformations than we wanted, so the desired rule is triggered.
>
>
> вт, 29 окт. 2019 г., 14:46 Vladimir Ozerov :
>
> > Hi Vladimir,
> >
> > I am sorry. Pushed, it works now.
> >
> > вт, 29 окт. 2019 г. в 14:41, Vladimir Sitnikov <
> > sitnikov.vladi...@gmail.com
> > >:
> >
> > > > mvn clean test
> > >
> > > [ERROR] The goal you specified requires a project to execute but there
> is
> > > no POM in this directory
> > >
> > > Vladimir, please push missing files
> > >
> > > Vladimir
> > >
> >
>

[jira] [Created] (CALCITE-3461) SqlToRelConverter substituteSubQuery bug

[TisNotT (Jira)]

TisNotT created CALCITE-3461:


 Summary: SqlToRelConverter substituteSubQuery  bug
 Key: CALCITE-3461
 URL: https://issues.apache.org/jira/browse/CALCITE-3461
 Project: Calcite
  Issue Type: Bug
Reporter: TisNotT


  final String sql = "select \n" + "  case \n"
+ "  when deptno in (1)   then '1'\n"
+ "when deptno in (220)  then '220' \n"
+ "else null end as deptno,\n"
+ "name,\n"
+ "count(distinct name)as num\n"
+ "from dept\n" + "\n"
+ "where \n"
+ "deptno in(1)\n"
+ "group by name,deptno ";

Sql like that ,SqlToRelConverter cannot convert from sql to node.
Bzc,substituteSubQuery handle wrong.



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

Request for access to Jenkins job configuration

[Danny Chan]

Hello,

It seems that in order to view/edit the job configuration on Jenkins, someone 
needs to be in the hudson-jobadmin group [1].

@Francis: Would it be possible to add me (danny0405) to the group. It appears
that only PMC chairs can do that.

[1] https://whimsy.apache.org/roster/group/hudson-jobadmin

Best,
Danny Chan

Re: [DISCUSS] State of the project 2019

[Stamatis Zampetakis]

Talks are a great way to spread the word about the project so don't
hesitate to update the respective part of the website as soon as the talk
is announced.

On Wed, Oct 30, 2019 at 5:16 AM Juan Pan  wrote:

> Sorry to disturb others.
>
>
>  @Danny Chan Hi, i have not received your personal mail, and i sent you
> email(yuzhao@gmail.com?) as well, but no reply. :(
>
>
>
> So i have to ping you in this way, please excuse me.
>
>
>
>
>
>
>  Juan Pan
>
>
> panj...@apache.org
> Juan Pan(Trista), Apache ShardingSphere
>
>
> On 10/25/2019 20:41，Danny Chan wrote：
> Oh, you can add my weixin(send personal mail for that) and I have a free
> ticket for the conference !
>
> Best,
> Danny Chan
> 在 2019年10月25日 +0800 PM6:29，Juan Pan ，写道：
> Hi Danny,
>
>
> I am interested in your coming talk in Beijing China. How to take part in
> it, can you give me more detail?
>
>
> Juan Pan
>
>
> panj...@apache.org
> Juan Pan(Trista), Apache ShardingSphere
>
>
> On 10/23/2019 18:23，Danny Chan wrote：
> I gave a talk last year in a university in
> France, and nobody in the audience had ever heard of Calcite before.
>
> Oops, that's a pity, I would also give a talk about Calcite on Flink
> Forward Asia 2019 of BeiJing China, hope more people would know Apache
> Calcite.
>
> Best,
> Danny Chan
> 在 2019年10月23日 +0800 PM2:36，dev@calcite.apache.org，写道：
>
> I gave a talk last year in a university in
> France, and nobody in the audience had ever heard of Calcite before.
>

[jira] [Created] (CALCITE-3460) Poor performance in RexReplacer for large queries

[Haisheng Yuan (Jira)]

Haisheng Yuan created CALCITE-3460:
--

 Summary: Poor performance in RexReplacer for large queries
 Key: CALCITE-3460
 URL: https://issues.apache.org/jira/browse/CALCITE-3460
 Project: Calcite
  Issue Type: Improvement
  Components: core
Reporter: Haisheng Yuan


We have queries that have tens of thousands of RexCalls. 
reducibleExps.indexOf(call) is an O(n) operation, which takes 50% of the 
running time, causing the query runs for ever until timed out.
In RexShuttle, ImmutableList iterator creation in {{visitList}} takes another 
5~7% of running time, and it is creating millions of temporary iterator object, 
not only time consuming, but also memory consuming.



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

Re: Problem with converters and possibly rule matching

[Seliverstov Igor]

Vladimir,

Probably it'll help you:

Seems the cause of issue in RelSubset.getParentRels()  The check used when
the planner schedules newly matched rules after successful transformation
(see VolcanoRuleCall.matchRecurse), it prevents the parent rule be applied
once again (here your logical project with an input having ANY distribution
doesn't satisfy a transformed input traits).

In our case we use another workaround, so there are also much more
transformations than we wanted, so the desired rule is triggered.


вт, 29 окт. 2019 г., 14:46 Vladimir Ozerov :

> Hi Vladimir,
>
> I am sorry. Pushed, it works now.
>
> вт, 29 окт. 2019 г. в 14:41, Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com
> >:
>
> > > mvn clean test
> >
> > [ERROR] The goal you specified requires a project to execute but there is
> > no POM in this directory
> >
> > Vladimir, please push missing files
> >
> > Vladimir
> >
>