[jira] [Updated] (CALCITE-4586) In piglet, allow creating a PigRelBuilder with custom "config.simplify()"
[ https://issues.apache.org/jira/browse/CALCITE-4586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4586: Description: Hi, piglet.PigRelBuilder#create, we set Hook.REL_BUILDER_SIMPLIFY to false: This may be not a suitable place to set "Hook.REL_BUILDER_SIMPLIFY", we should use this in user code, not in the frame code, cuz once we done this in frame code, we can not change this config anymore. This change may be perceived if you are using piglet.PigRelBuilder, it is expected that the change will not be large and should be positive, cuz the UTs are almost unchanged and all passed. You can set "config.simplify()" to false to keep the behavior the same was: Hi, piglet.PigRelBuilder#create, we set Hook.REL_BUILDER_SIMPLIFY to false: This may be not a suitable place to set "Hook.REL_BUILDER_SIMPLIFY", we should use this in user code, not in the frame code, cuz once we done this in frame code, we can not change this config anymore. This change may be perceived if you are using piglet.PigRelBuilder, it is expected that the change will not be large and should be positive, cuz the UTs are almost unchanged and all passed. You can set > In piglet, allow creating a PigRelBuilder with custom "config.simplify()" > - > > Key: CALCITE-4586 > URL: https://issues.apache.org/jira/browse/CALCITE-4586 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Critical > Fix For: 1.27.0 > > > Hi, piglet.PigRelBuilder#create, we set Hook.REL_BUILDER_SIMPLIFY to false: > This may be not a suitable place to set "Hook.REL_BUILDER_SIMPLIFY", we > should use this in user code, not in the frame code, cuz once we done this in > frame code, we can not change this config anymore. > > This change may be perceived if you are using piglet.PigRelBuilder, > it is expected that the change will not be large and should be positive, cuz > the UTs are almost unchanged and all passed. > > You can set "config.simplify()" to false to keep the behavior the same > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4586) In piglet, allow creating a PigRelBuilder with custom "config.simplify()"
[
https://issues.apache.org/jira/browse/CALCITE-4586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiatao Tao updated CALCITE-4586:
Description:
Hi, piglet.PigRelBuilder#create, we set Hook.REL_BUILDER_SIMPLIFY to false:
This may be not a suitable place to set "Hook.REL_BUILDER_SIMPLIFY", we should
use this in user code, not in the frame code, cuz once we done this in frame
code, we can not change this config anymore.
This change may be perceived if you are using piglet.PigRelBuilder,
it is expected that the change will not be large and should be positive, cuz
the UTs are almost unchanged and all passed.
You can set
was:
Hi, in PigRelBuilder#create, we set Hook.REL_BUILDER_SIMPLIFY to false:
{{}}
I have two doubts:
1. Why we set FALSE here cuz its default value is true;
2. This maybe not the suitable place to set "Hook.REL_BUILDER_SIMPLIFY", IMO
we should use this in user code, not in the frame code, cuz once we done this
in frame code, we can not change this config anymore.
> In piglet, allow creating a PigRelBuilder with custom "config.simplify()"
> -
>
> Key: CALCITE-4586
> URL: https://issues.apache.org/jira/browse/CALCITE-4586
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Critical
> Fix For: 1.27.0
>
>
> Hi, piglet.PigRelBuilder#create, we set Hook.REL_BUILDER_SIMPLIFY to false:
> This may be not a suitable place to set "Hook.REL_BUILDER_SIMPLIFY", we
> should use this in user code, not in the frame code, cuz once we done this in
> frame code, we can not change this config anymore.
>
> This change may be perceived if you are using piglet.PigRelBuilder,
> it is expected that the change will not be large and should be positive, cuz
> the UTs are almost unchanged and all passed.
>
> You can set
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4586) In piglet, allow creating a PigRelBuilder with custom "config.simplify()"
[
https://issues.apache.org/jira/browse/CALCITE-4586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiatao Tao updated CALCITE-4586:
Description:
Hi, in PigRelBuilder#create, we set Hook.REL_BUILDER_SIMPLIFY to false:
{{}}
I have two doubts:
1. Why we set FALSE here cuz its default value is true;
2. This maybe not the suitable place to set "Hook.REL_BUILDER_SIMPLIFY", IMO
we should use this in user code, not in the frame code, cuz once we done this
in frame code, we can not change this config anymore.
> In piglet, allow creating a PigRelBuilder with custom "config.simplify()"
> -
>
> Key: CALCITE-4586
> URL: https://issues.apache.org/jira/browse/CALCITE-4586
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Critical
> Fix For: 1.27.0
>
>
> Hi, in PigRelBuilder#create, we set Hook.REL_BUILDER_SIMPLIFY to false:
>
> {{}}
>
> I have two doubts:
> 1. Why we set FALSE here cuz its default value is true;
> 2. This maybe not the suitable place to set "Hook.REL_BUILDER_SIMPLIFY", IMO
> we should use this in user code, not in the frame code, cuz once we done this
> in frame code, we can not change this config anymore.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4578) redundant HepPlanner#buildFinalPlan when there's no rule fired in the program
[
https://issues.apache.org/jira/browse/CALCITE-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17327064#comment-17327064
]
Jiatao Tao commented on CALCITE-4578:
-
Yes, it's not the latest version, and in the latest version, this kind of query
is a VALUES op.
> redundant HepPlanner#buildFinalPlan when there's no rule fired in the program
> -
>
> Key: CALCITE-4578
> URL: https://issues.apache.org/jira/browse/CALCITE-4578
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Attachments: image-2021-04-11-17-42-38-595.png
>
>
> Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3,
> 'three')...(1, 'ten thousand');
> It generates a Union node with 1 inputs, and the performance is poor,
> here's the profile:
> !image-2021-04-11-17-42-38-595.png|width=1086,height=240!
> We create a program(HepProgram) to do the union merge, in this case, we only
> have one union, so the rule is not fired, but it will still build the
> buildFinalPlan, and AbstractRelNode#explain has performance issue in this
> case(see the flame graph):
> {code:java}
> public RelNode findBestExp() {
> assert root != null;
> executeProgram(mainProgram);
> // Get rid of everything except what's in the final plan.
> collectGarbage();
> return buildFinalPlan(root);
> }
> {code}
> And the union has large inputs, so the performance is poor(in
> SetOp#replaceInput, we have to recomputeDigest ), we can skip buildFinalPlan
> if there's no rule fired.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4586) In piglet, allow creating a PigRelBuilder with custom "config.simplify()"
[ https://issues.apache.org/jira/browse/CALCITE-4586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17327063#comment-17327063 ] Jiatao Tao commented on CALCITE-4586: - Thanks for your work! > In piglet, allow creating a PigRelBuilder with custom "config.simplify()" > - > > Key: CALCITE-4586 > URL: https://issues.apache.org/jira/browse/CALCITE-4586 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Critical > Fix For: 1.27.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4583) Make simplification configurable in "RelBuilder#filter"
[ https://issues.apache.org/jira/browse/CALCITE-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17327062#comment-17327062 ] Jiatao Tao commented on CALCITE-4583: - Thank you for your work, [~zabetak] > Make simplification configurable in "RelBuilder#filter" > --- > > Key: CALCITE-4583 > URL: https://issues.apache.org/jira/browse/CALCITE-4583 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Critical > Labels: pull-request-available > Fix For: 1.27.0 > > Attachments: image-2021-04-15-20-52-15-757.png, > image-2021-04-19-10-45-21-768.png, image-2021-04-19-10-45-48-287.png > > Time Spent: 1.5h > Remaining Estimate: 0h > > Previous in CALCITE-2338, we make simplification configurable in most methods > except RelBuilder#filter, this Jira aims to cover this method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4583) Make simplification configurable in "RelBuilder#filter"
[ https://issues.apache.org/jira/browse/CALCITE-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4583: Summary: Make simplification configurable in "RelBuilder#filter" (was: Make simplification configurable by "RelBuilder.Config#simplify()" in "RelBuilder#filter") > Make simplification configurable in "RelBuilder#filter" > --- > > Key: CALCITE-4583 > URL: https://issues.apache.org/jira/browse/CALCITE-4583 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Critical > Labels: pull-request-available > Attachments: image-2021-04-15-20-52-15-757.png, > image-2021-04-19-10-45-21-768.png, image-2021-04-19-10-45-48-287.png > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Previous in CALCITE-2338, we make simplification configurable in most methods > except RelBuilder#filter, this Jira aims to cover this method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4583) Make simplification configurable by "RelBuilder.Config#simplify()" in "RelBuilder#filter"
[ https://issues.apache.org/jira/browse/CALCITE-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4583: Summary: Make simplification configurable by "RelBuilder.Config#simplify()" in "RelBuilder#filter" (was: Make "RelBuilder#filter" to be configurable by "RelBuilder.Config#simplify()") > Make simplification configurable by "RelBuilder.Config#simplify()" in > "RelBuilder#filter" > - > > Key: CALCITE-4583 > URL: https://issues.apache.org/jira/browse/CALCITE-4583 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Critical > Labels: pull-request-available > Attachments: image-2021-04-15-20-52-15-757.png, > image-2021-04-19-10-45-21-768.png, image-2021-04-19-10-45-48-287.png > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Previous in CALCITE-2338, we make simplification configurable in most methods > except RelBuilder#filter, this Jira aims to cover this method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4583) Make "RelBuilder#filter" to be configurable by "RelBuilder.Config#simplify()"
[ https://issues.apache.org/jira/browse/CALCITE-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17324654#comment-17324654 ] Jiatao Tao edited comment on CALCITE-4583 at 4/19/21, 2:55 AM: --- [~julianhyde] TBH, I don't think I add any knob, just align with these. When I set "config.simplify()" to false, RelBuilder#project/RelBuilder#join will not call the RexSimplify, but RelBuilder#filter still. It makes no sense. !image-2021-04-19-10-45-21-768.png|width=453,height=452! !image-2021-04-19-10-45-48-287.png|width=456,height=356! was (Author: aron.tao): TBH, I don't think I add any Just align with these !image-2021-04-19-10-45-21-768.png|width=453,height=452! !image-2021-04-19-10-45-48-287.png|width=456,height=356! > Make "RelBuilder#filter" to be configurable by "RelBuilder.Config#simplify()" > - > > Key: CALCITE-4583 > URL: https://issues.apache.org/jira/browse/CALCITE-4583 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Critical > Labels: pull-request-available > Attachments: image-2021-04-15-20-52-15-757.png, > image-2021-04-19-10-45-21-768.png, image-2021-04-19-10-45-48-287.png > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Previous in CALCITE-2338, we make simplification configurable in most methods > except RelBuilder#filter, this Jira aims to cover this method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4583) Make "RelBuilder#filter" to be configurable by "RelBuilder.Config#simplify()"
[ https://issues.apache.org/jira/browse/CALCITE-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17324654#comment-17324654 ] Jiatao Tao edited comment on CALCITE-4583 at 4/19/21, 2:55 AM: --- [~julianhyde] TBH, I don't think I add any knob, just align with these. When I set "config.simplify()" to false, RelBuilder#project/RelBuilder#join will not call the RexSimplify, but RelBuilder#filter still will. It makes no sense. !image-2021-04-19-10-45-21-768.png|width=453,height=452! !image-2021-04-19-10-45-48-287.png|width=456,height=356! was (Author: aron.tao): [~julianhyde] TBH, I don't think I add any knob, just align with these. When I set "config.simplify()" to false, RelBuilder#project/RelBuilder#join will not call the RexSimplify, but RelBuilder#filter still. It makes no sense. !image-2021-04-19-10-45-21-768.png|width=453,height=452! !image-2021-04-19-10-45-48-287.png|width=456,height=356! > Make "RelBuilder#filter" to be configurable by "RelBuilder.Config#simplify()" > - > > Key: CALCITE-4583 > URL: https://issues.apache.org/jira/browse/CALCITE-4583 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Critical > Labels: pull-request-available > Attachments: image-2021-04-15-20-52-15-757.png, > image-2021-04-19-10-45-21-768.png, image-2021-04-19-10-45-48-287.png > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Previous in CALCITE-2338, we make simplification configurable in most methods > except RelBuilder#filter, this Jira aims to cover this method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4583) Make "RelBuilder#filter" to be configurable by "RelBuilder.Config#simplify()"
[ https://issues.apache.org/jira/browse/CALCITE-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17324654#comment-17324654 ] Jiatao Tao edited comment on CALCITE-4583 at 4/19/21, 2:52 AM: --- TBH, I don't think I add any Just align with these !image-2021-04-19-10-45-21-768.png|width=453,height=452! !image-2021-04-19-10-45-48-287.png|width=456,height=356! was (Author: aron.tao): Just align with these !image-2021-04-19-10-45-21-768.png|width=453,height=452! !image-2021-04-19-10-45-48-287.png|width=456,height=356! > Make "RelBuilder#filter" to be configurable by "RelBuilder.Config#simplify()" > - > > Key: CALCITE-4583 > URL: https://issues.apache.org/jira/browse/CALCITE-4583 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Critical > Labels: pull-request-available > Attachments: image-2021-04-15-20-52-15-757.png, > image-2021-04-19-10-45-21-768.png, image-2021-04-19-10-45-48-287.png > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Previous in CALCITE-2338, we make simplification configurable in most methods > except RelBuilder#filter, this Jira aims to cover this method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4583) Make "RelBuilder#filter" to be configurable by "RelBuilder.Config#simplify()"
[ https://issues.apache.org/jira/browse/CALCITE-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4583: Summary: Make "RelBuilder#filter" to be configurable by "RelBuilder.Config#simplify()" (was: Make simplification controllable in "RelBuilder#filter") > Make "RelBuilder#filter" to be configurable by "RelBuilder.Config#simplify()" > - > > Key: CALCITE-4583 > URL: https://issues.apache.org/jira/browse/CALCITE-4583 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Critical > Labels: pull-request-available > Attachments: image-2021-04-15-20-52-15-757.png, > image-2021-04-19-10-45-21-768.png, image-2021-04-19-10-45-48-287.png > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Previous in CALCITE-2338, we make simplification configurable in most methods > except RelBuilder#filter, this Jira aims to cover this method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4583) Make simplification controllable in "RelBuilder#filter"
[ https://issues.apache.org/jira/browse/CALCITE-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17324654#comment-17324654 ] Jiatao Tao edited comment on CALCITE-4583 at 4/19/21, 2:46 AM: --- Just align with these !image-2021-04-19-10-45-21-768.png|width=453,height=452! !image-2021-04-19-10-45-48-287.png|width=456,height=356! was (Author: aron.tao): !image-2021-04-19-10-45-21-768.png|width=453,height=452! !image-2021-04-19-10-45-48-287.png|width=456,height=356! > Make simplification controllable in "RelBuilder#filter" > --- > > Key: CALCITE-4583 > URL: https://issues.apache.org/jira/browse/CALCITE-4583 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Critical > Labels: pull-request-available > Attachments: image-2021-04-15-20-52-15-757.png, > image-2021-04-19-10-45-21-768.png, image-2021-04-19-10-45-48-287.png > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Previous in CALCITE-2338, we make simplification configurable in most methods > except RelBuilder#filter, this Jira aims to cover this method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4583) Make simplification controllable in "RelBuilder#filter"
[ https://issues.apache.org/jira/browse/CALCITE-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17324654#comment-17324654 ] Jiatao Tao commented on CALCITE-4583: - !image-2021-04-19-10-45-21-768.png|width=453,height=452! !image-2021-04-19-10-45-48-287.png|width=456,height=356! > Make simplification controllable in "RelBuilder#filter" > --- > > Key: CALCITE-4583 > URL: https://issues.apache.org/jira/browse/CALCITE-4583 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Critical > Labels: pull-request-available > Attachments: image-2021-04-15-20-52-15-757.png, > image-2021-04-19-10-45-21-768.png, image-2021-04-19-10-45-48-287.png > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Previous in CALCITE-2338, we make simplification configurable in most methods > except RelBuilder#filter, this Jira aims to cover this method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4583) Make simplification controllable in "RelBuilder#filter"
[ https://issues.apache.org/jira/browse/CALCITE-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4583: Attachment: image-2021-04-19-10-45-48-287.png > Make simplification controllable in "RelBuilder#filter" > --- > > Key: CALCITE-4583 > URL: https://issues.apache.org/jira/browse/CALCITE-4583 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Critical > Labels: pull-request-available > Attachments: image-2021-04-15-20-52-15-757.png, > image-2021-04-19-10-45-21-768.png, image-2021-04-19-10-45-48-287.png > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Previous in CALCITE-2338, we make simplification configurable in most methods > except RelBuilder#filter, this Jira aims to cover this method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4583) Make simplification controllable in "RelBuilder#filter"
[ https://issues.apache.org/jira/browse/CALCITE-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4583: Attachment: image-2021-04-19-10-45-21-768.png > Make simplification controllable in "RelBuilder#filter" > --- > > Key: CALCITE-4583 > URL: https://issues.apache.org/jira/browse/CALCITE-4583 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Critical > Labels: pull-request-available > Attachments: image-2021-04-15-20-52-15-757.png, > image-2021-04-19-10-45-21-768.png, image-2021-04-19-10-45-48-287.png > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Previous in CALCITE-2338, we make simplification configurable in most methods > except RelBuilder#filter, this Jira aims to cover this method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4583) Make simplification controllable in "RelBuilder#filter"
[ https://issues.apache.org/jira/browse/CALCITE-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17324651#comment-17324651 ] Jiatao Tao commented on CALCITE-4583: - [~julianhyde] Previous in CALCITE-2338, we make simplification configurable in most methods that calling RexSimplify, except RelBuilder#filter, this Jira aims to cover this method. > Make simplification controllable in "RelBuilder#filter" > --- > > Key: CALCITE-4583 > URL: https://issues.apache.org/jira/browse/CALCITE-4583 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Critical > Labels: pull-request-available > Attachments: image-2021-04-15-20-52-15-757.png > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Previous in CALCITE-2338, we make simplification configurable in most methods > except RelBuilder#filter, this Jira aims to cover this method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4587) Set "spark.driver.bindAddress" explicitly to avoid "BindException" thrown by Spark
[ https://issues.apache.org/jira/browse/CALCITE-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4587: Description: The problem may be the wrong hostname in "/etc/hosts", a way to solve this problem is to set "spark.driver.bindAddress" explicitly, I've tested and works. was:The problem may be the wrong hostname in "/etc/hosts", a way to solve this problem is to set "spark.driver.bindAddress" explicitly. > Set "spark.driver.bindAddress" explicitly to avoid "BindException" thrown by > Spark > -- > > Key: CALCITE-4587 > URL: https://issues.apache.org/jira/browse/CALCITE-4587 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > The problem may be the wrong hostname in "/etc/hosts", a way to solve this > problem is to set "spark.driver.bindAddress" explicitly, I've tested and > works. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4587) Set "spark.driver.bindAddress" explicitly to avoid "BindException" thrown by Spark
[ https://issues.apache.org/jira/browse/CALCITE-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4587: Description: The problem may be the wrong hostname in "/etc/hosts", a way to solve this problem is to set "spark.driver.bindAddress" explicitly. (was: The problem may be the wrong hostname in "/etc/hosts", ) > Set "spark.driver.bindAddress" explicitly to avoid "BindException" thrown by > Spark > -- > > Key: CALCITE-4587 > URL: https://issues.apache.org/jira/browse/CALCITE-4587 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > The problem may be the wrong hostname in "/etc/hosts", a way to solve this > problem is to set "spark.driver.bindAddress" explicitly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4587) Set "spark.driver.bindAddress" explicitly to avoid "BindException" thrown by Spark
[ https://issues.apache.org/jira/browse/CALCITE-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4587: Description: The problem may be the wrong hostname in "/etc/hosts", > Set "spark.driver.bindAddress" explicitly to avoid "BindException" thrown by > Spark > -- > > Key: CALCITE-4587 > URL: https://issues.apache.org/jira/browse/CALCITE-4587 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > The problem may be the wrong hostname in "/etc/hosts", -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4587) Set "spark.driver.bindAddress" explicitly to avoid "BindException" thrown by Spark
[ https://issues.apache.org/jira/browse/CALCITE-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4587: Summary: Set "spark.driver.bindAddress" explicitly to avoid "BindException" thrown by Spark (was: Set "spark.driver.bindAddress" explicitly to avoid java.net.BindException throw by Spark) > Set "spark.driver.bindAddress" explicitly to avoid "BindException" thrown by > Spark > -- > > Key: CALCITE-4587 > URL: https://issues.apache.org/jira/browse/CALCITE-4587 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4587) Set "spark.driver.bindAddress" explicitly to avoid java.net.BindException throw by Spark
Jiatao Tao created CALCITE-4587: --- Summary: Set "spark.driver.bindAddress" explicitly to avoid java.net.BindException throw by Spark Key: CALCITE-4587 URL: https://issues.apache.org/jira/browse/CALCITE-4587 Project: Calcite Issue Type: Improvement Components: core Reporter: Jiatao Tao Assignee: Jiatao Tao -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4586) In piglet, allow creating a PigRelBuilder with custom "config.simplify()"
[ https://issues.apache.org/jira/browse/CALCITE-4586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4586: Summary: In piglet, allow creating a PigRelBuilder with custom "config.simplify()" (was: Make "RelBuilder.Config#simplify" configurable in "piglet.PigRelBuilder") > In piglet, allow creating a PigRelBuilder with custom "config.simplify()" > - > > Key: CALCITE-4586 > URL: https://issues.apache.org/jira/browse/CALCITE-4586 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Critical > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4586) Make "RelBuilder.Config#simplify" configurable in "piglet.PigRelBuilder"
Jiatao Tao created CALCITE-4586: --- Summary: Make "RelBuilder.Config#simplify" configurable in "piglet.PigRelBuilder" Key: CALCITE-4586 URL: https://issues.apache.org/jira/browse/CALCITE-4586 Project: Calcite Issue Type: Improvement Components: core Reporter: Jiatao Tao Assignee: Jiatao Tao -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4578) redundant HepPlanner#buildFinalPlan when there's no rule fired in the program
[
https://issues.apache.org/jira/browse/CALCITE-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322576#comment-17322576
]
Jiatao Tao commented on CALCITE-4578:
-
[~julianhyde] Really thanks for your suggestion, this cod change is to the
optimizer, not end-users, can you give some revise opinion, I think it really
helps.
> redundant HepPlanner#buildFinalPlan when there's no rule fired in the program
> -
>
> Key: CALCITE-4578
> URL: https://issues.apache.org/jira/browse/CALCITE-4578
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Attachments: image-2021-04-11-17-42-38-595.png
>
>
> Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3,
> 'three')...(1, 'ten thousand');
> It generates a Union node with 1 inputs, and the performance is poor,
> here's the profile:
> !image-2021-04-11-17-42-38-595.png|width=1086,height=240!
> We create a program(HepProgram) to do the union merge, in this case, we only
> have one union, so the rule is not fired, but it will still build the
> buildFinalPlan, and AbstractRelNode#explain has performance issue in this
> case(see the flame graph):
> {code:java}
> public RelNode findBestExp() {
> assert root != null;
> executeProgram(mainProgram);
> // Get rid of everything except what's in the final plan.
> collectGarbage();
> return buildFinalPlan(root);
> }
> {code}
> And the union has large inputs, so the performance is poor(in
> SetOp#replaceInput, we have to recomputeDigest ), we can skip buildFinalPlan
> if there's no rule fired.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4583) Make simplification controllable in "RelBuilder#filter"
[ https://issues.apache.org/jira/browse/CALCITE-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322573#comment-17322573 ] Jiatao Tao commented on CALCITE-4583: - Hi [~julianhyde], in relbuilder, we make simplification configurable in most methods except RelBuilder#filter, this Jira aims to align this. > Make simplification controllable in "RelBuilder#filter" > --- > > Key: CALCITE-4583 > URL: https://issues.apache.org/jira/browse/CALCITE-4583 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Critical > Labels: pull-request-available > Attachments: image-2021-04-15-20-52-15-757.png > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Previous in CALCITE-2338, we make simplification configurable in most methods > except RelBuilder#filter, this Jira aims to cover this method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4583) Make simplification controllable in "RelBuilder#filter"
[ https://issues.apache.org/jira/browse/CALCITE-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4583: Summary: Make simplification controllable in "RelBuilder#filter" (was: Make simplification API more conservative in "RelBuilder#filter") > Make simplification controllable in "RelBuilder#filter" > --- > > Key: CALCITE-4583 > URL: https://issues.apache.org/jira/browse/CALCITE-4583 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Critical > Labels: pull-request-available > Attachments: image-2021-04-15-20-52-15-757.png > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Previous in CALCITE-2338, we make simplification configurable in most methods > except RelBuilder#filter, this Jira aims to cover this method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3122) Convert Pig Latin scripts into Calcite logical plans
[ https://issues.apache.org/jira/browse/CALCITE-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322169#comment-17322169 ] Jiatao Tao commented on CALCITE-3122: - [~khaitran] Hi, I found that RelBuilder#simplify() is set to false in org.apache.calcite.piglet.PigRelBuilder#create, can you explain this a bit? > Convert Pig Latin scripts into Calcite logical plans > - > > Key: CALCITE-3122 > URL: https://issues.apache.org/jira/browse/CALCITE-3122 > Project: Calcite > Issue Type: New Feature > Components: core, piglet >Reporter: Khai Tran >Assignee: Julian Hyde >Priority: Major > Labels: pull-request-available > Fix For: 1.21.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > We create an internal Calcite repo at LinkedIn and develop APIs to parse any > Pig Latin scripts into Calcite logical plan. The code was tested in nearly > ~1000 Pig scripts written at LinkedIn. > Changes: > 1. piglet: main conversion code live there, include: > * APIs to convert any Pig scripts into RelNode plans or SQL statements > * Use Pig Grunt parser to parse Pig Latin scripts into Pig logical plan > (DAGs) > * Convert Pig schemas into RelDatatype > * Traverse through Pig expression plan and convert Pig expressions into > RexNodes > * Map some basic Pig UDFs to Calcite SQL operators > * Build Calcite UDFs for any other Pig UDFs, including UDFs written in both > Java and Python > * Traverse (DFS) through Pig logical plans to convert each Pig logical nodes > to RelNodes > * Have an optimizer rule to optimize Pig group/cogroup into Aggregate > operators > 2. core: > * Implement other RelNode in Rel2Sql so that Pig can be translated into SQL > * Other minor changes in a few other classes to make Pig to Calcite works -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4583) Make simplification API more conservative in "RelBuilder#filter"
[ https://issues.apache.org/jira/browse/CALCITE-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17322157#comment-17322157 ] Jiatao Tao commented on CALCITE-4583: - Found a improvement for FilterReduceExpressionsRule#onMatch, we used only consider newConditionExp.isAlwaysTrue(), but not newConditionExp.isAlwaysFalse(), this simplify is done by RelBuilder#filter(): !image-2021-04-15-20-52-15-757.png|width=831,height=128! > Make simplification API more conservative in "RelBuilder#filter" > > > Key: CALCITE-4583 > URL: https://issues.apache.org/jira/browse/CALCITE-4583 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Critical > Labels: pull-request-available > Attachments: image-2021-04-15-20-52-15-757.png > > Time Spent: 1h > Remaining Estimate: 0h > > Previous in CALCITE-2338, we make simplification configurable in most methods > except RelBuilder#filter, this Jira aims to cover this method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4583) Make simplification API more conservative in "RelBuilder#filter"
[ https://issues.apache.org/jira/browse/CALCITE-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4583: Attachment: (was: image-2021-04-15-20-52-04-725.png) > Make simplification API more conservative in "RelBuilder#filter" > > > Key: CALCITE-4583 > URL: https://issues.apache.org/jira/browse/CALCITE-4583 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Critical > Labels: pull-request-available > Attachments: image-2021-04-15-20-52-15-757.png > > Time Spent: 1h > Remaining Estimate: 0h > > Previous in CALCITE-2338, we make simplification configurable in most methods > except RelBuilder#filter, this Jira aims to cover this method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4583) Make simplification API more conservative in "RelBuilder#filter"
[ https://issues.apache.org/jira/browse/CALCITE-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4583: Attachment: image-2021-04-15-20-52-15-757.png > Make simplification API more conservative in "RelBuilder#filter" > > > Key: CALCITE-4583 > URL: https://issues.apache.org/jira/browse/CALCITE-4583 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Critical > Labels: pull-request-available > Attachments: image-2021-04-15-20-52-15-757.png > > Time Spent: 1h > Remaining Estimate: 0h > > Previous in CALCITE-2338, we make simplification configurable in most methods > except RelBuilder#filter, this Jira aims to cover this method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4583) Make simplification API more conservative in "RelBuilder#filter"
[ https://issues.apache.org/jira/browse/CALCITE-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4583: Attachment: (was: image-2021-04-15-20-52-00-046.png) > Make simplification API more conservative in "RelBuilder#filter" > > > Key: CALCITE-4583 > URL: https://issues.apache.org/jira/browse/CALCITE-4583 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Critical > Labels: pull-request-available > Attachments: image-2021-04-15-20-52-15-757.png > > Time Spent: 1h > Remaining Estimate: 0h > > Previous in CALCITE-2338, we make simplification configurable in most methods > except RelBuilder#filter, this Jira aims to cover this method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4583) Make simplification API more conservative in "RelBuilder#filter"
[ https://issues.apache.org/jira/browse/CALCITE-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4583: Attachment: image-2021-04-15-20-52-00-046.png > Make simplification API more conservative in "RelBuilder#filter" > > > Key: CALCITE-4583 > URL: https://issues.apache.org/jira/browse/CALCITE-4583 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Critical > Labels: pull-request-available > Attachments: image-2021-04-15-20-52-15-757.png > > Time Spent: 1h > Remaining Estimate: 0h > > Previous in CALCITE-2338, we make simplification configurable in most methods > except RelBuilder#filter, this Jira aims to cover this method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4583) Make simplification API more conservative in "RelBuilder#filter"
[ https://issues.apache.org/jira/browse/CALCITE-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4583: Attachment: image-2021-04-15-20-52-04-725.png > Make simplification API more conservative in "RelBuilder#filter" > > > Key: CALCITE-4583 > URL: https://issues.apache.org/jira/browse/CALCITE-4583 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Critical > Labels: pull-request-available > Attachments: image-2021-04-15-20-52-15-757.png > > Time Spent: 1h > Remaining Estimate: 0h > > Previous in CALCITE-2338, we make simplification configurable in most methods > except RelBuilder#filter, this Jira aims to cover this method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4583) Make simplification API more conservative in "RelBuilder#filter"
Jiatao Tao created CALCITE-4583: --- Summary: Make simplification API more conservative in "RelBuilder#filter" Key: CALCITE-4583 URL: https://issues.apache.org/jira/browse/CALCITE-4583 Project: Calcite Issue Type: Improvement Components: core Reporter: Jiatao Tao Assignee: Jiatao Tao Previous in CALCITE-2338, we make simplification configurable in most methods except RelBuilder#filter, this Jira aims to cover this method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4578) redundant HepPlanner#buildFinalPlan when there's no rule fired in the program
[
https://issues.apache.org/jira/browse/CALCITE-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318988#comment-17318988
]
Jiatao Tao edited comment on CALCITE-4578 at 4/12/21, 6:34 AM:
---
Hi [~julianhyde], thanks for your suggestion.
Yes, the best plan should be a values operator and I test the example SQL and
it's as expected. But users can still have very large union SQL(I have met
several times).
was (Author: aron.tao):
Hi [~julianhyde], thanks for your suggestion.
Yes, the best plan should be a values operator, for the simple case, it's as
expected, but for my scenario, it has type coercion(has CAST), so it can not
produce a VALUE(SqlToRelConverter#convertValuesImpl).
> redundant HepPlanner#buildFinalPlan when there's no rule fired in the program
> -
>
> Key: CALCITE-4578
> URL: https://issues.apache.org/jira/browse/CALCITE-4578
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Attachments: image-2021-04-11-17-42-38-595.png
>
>
> Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3,
> 'three')...(1, 'ten thousand');
> It generates a Union node with 1 inputs, and the performance is poor,
> here's the profile:
> !image-2021-04-11-17-42-38-595.png|width=1086,height=240!
> We create a program(HepProgram) to do the union merge, in this case, we only
> have one union, so the rule is not fired, but it will still build the
> buildFinalPlan, and AbstractRelNode#explain has performance issue in this
> case(see the flame graph):
> {code:java}
> public RelNode findBestExp() {
> assert root != null;
> executeProgram(mainProgram);
> // Get rid of everything except what's in the final plan.
> collectGarbage();
> return buildFinalPlan(root);
> }
> {code}
> And the union has large inputs, so the performance is poor(in
> SetOp#replaceInput, we have to recomputeDigest ), we can skip buildFinalPlan
> if there's no rule fired.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4578) redundant HepPlanner#buildFinalPlan when there's no rule fired in the program
[
https://issues.apache.org/jira/browse/CALCITE-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318988#comment-17318988
]
Jiatao Tao edited comment on CALCITE-4578 at 4/12/21, 6:21 AM:
---
Hi [~julianhyde], thanks for your suggestion.
Yes, the best plan should be a values operator, for the simple case, it's as
expected, but for my scenario, it has type coercion(has CAST), so it can not
produce a VALUE(SqlToRelConverter#convertValuesImpl).
was (Author: aron.tao):
Hi [~julianhyde], thanks for your suggestion.
Yes, the best plan should be a values operator and I test the example SQL and
it's as expected. But users can still have very large union SQL(I have met
several times).
> redundant HepPlanner#buildFinalPlan when there's no rule fired in the program
> -
>
> Key: CALCITE-4578
> URL: https://issues.apache.org/jira/browse/CALCITE-4578
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Attachments: image-2021-04-11-17-42-38-595.png
>
>
> Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3,
> 'three')...(1, 'ten thousand');
> It generates a Union node with 1 inputs, and the performance is poor,
> here's the profile:
> !image-2021-04-11-17-42-38-595.png|width=1086,height=240!
> We create a program(HepProgram) to do the union merge, in this case, we only
> have one union, so the rule is not fired, but it will still build the
> buildFinalPlan, and AbstractRelNode#explain has performance issue in this
> case(see the flame graph):
> {code:java}
> public RelNode findBestExp() {
> assert root != null;
> executeProgram(mainProgram);
> // Get rid of everything except what's in the final plan.
> collectGarbage();
> return buildFinalPlan(root);
> }
> {code}
> And the union has large inputs, so the performance is poor(in
> SetOp#replaceInput, we have to recomputeDigest ), we can skip buildFinalPlan
> if there's no rule fired.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4578) redundant HepPlanner#buildFinalPlan when there's no rule fired in the program
[
https://issues.apache.org/jira/browse/CALCITE-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318988#comment-17318988
]
Jiatao Tao commented on CALCITE-4578:
-
Hi [~julianhyde], thanks for your suggestion.
Yes, the best plan should be a values operator and I test the example SQL and
it's as expected. But users can still have very large union SQL(I have met
several times).
> redundant HepPlanner#buildFinalPlan when there's no rule fired in the program
> -
>
> Key: CALCITE-4578
> URL: https://issues.apache.org/jira/browse/CALCITE-4578
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Attachments: image-2021-04-11-17-42-38-595.png
>
>
> Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3,
> 'three')...(1, 'ten thousand');
> It generates a Union node with 1 inputs, and the performance is poor,
> here's the profile:
> !image-2021-04-11-17-42-38-595.png|width=1086,height=240!
> We create a program(HepProgram) to do the union merge, in this case, we only
> have one union, so the rule is not fired, but it will still build the
> buildFinalPlan, and AbstractRelNode#explain has performance issue in this
> case(see the flame graph):
> {code:java}
> public RelNode findBestExp() {
> assert root != null;
> executeProgram(mainProgram);
> // Get rid of everything except what's in the final plan.
> collectGarbage();
> return buildFinalPlan(root);
> }
> {code}
> And the union has large inputs, so the performance is poor(in
> SetOp#replaceInput, we have to recomputeDigest ), we can skip buildFinalPlan
> if there's no rule fired.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4578) redundant HepPlanner#buildFinalPlan when there's no rule fired in the program
[
https://issues.apache.org/jira/browse/CALCITE-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiatao Tao updated CALCITE-4578:
Summary: redundant HepPlanner#buildFinalPlan when there's no rule fired in
the program (was: skip HepPlanner#buildFinalPlan when there's no rule fired in
the program)
> redundant HepPlanner#buildFinalPlan when there's no rule fired in the program
> -
>
> Key: CALCITE-4578
> URL: https://issues.apache.org/jira/browse/CALCITE-4578
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Attachments: image-2021-04-11-17-42-38-595.png
>
>
> Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3,
> 'three')...(1, 'ten thousand');
> It generates a Union node with 1 inputs, and the performance is poor,
> here's the profile:
> !image-2021-04-11-17-42-38-595.png|width=1086,height=240!
> We create a program(HepProgram) to do the union merge, in this case, we only
> have one union, so the rule is not fired, but it will still build the
> buildFinalPlan, and AbstractRelNode#explain has performance issue in this
> case(see the flame graph):
> {code:java}
> public RelNode findBestExp() {
> assert root != null;
> executeProgram(mainProgram);
> // Get rid of everything except what's in the final plan.
> collectGarbage();
> return buildFinalPlan(root);
> }
> {code}
> And the union has large inputs, so the performance is poor(in
> SetOp#replaceInput, we have to recomputeDigest ), we can skip buildFinalPlan
> if there's no rule fired.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4578) skip HepPlanner#buildFinalPlan when there's no rule fired in the program
[
https://issues.apache.org/jira/browse/CALCITE-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiatao Tao updated CALCITE-4578:
Description:
Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3,
'three')...(1, 'ten thousand');
It generates a Union node with 1 inputs, and the performance is poor,
here's the profile:
!image-2021-04-11-17-42-38-595.png|width=1086,height=240!
We create a program(HepProgram) to do the union merge, in this case, we only
have one union, so the rule is not fired, but it will still build the
buildFinalPlan, and AbstractRelNode#explain has performance issue in this
case(see the flame graph):
{code:java}
public RelNode findBestExp() {
assert root != null;
executeProgram(mainProgram);
// Get rid of everything except what's in the final plan.
collectGarbage();
return buildFinalPlan(root);
}
{code}
And the union has large inputs, so the performance is poor(in
SetOp#replaceInput, we have to recomputeDigest ), we can skip buildFinalPlan if
there's no rule fired.
was:
Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3,
'three')...(1, 'ten thousand');
It generates a Union node with 1 inputs, and the performance is poor,
here's the profile:
!image-2021-04-11-17-42-38-595.png|width=1086,height=240!
We create a program(HepProgram) to do the union merge, in this case, we only
have one union, so the rule is not applied, but it will still build the
buildFinalPlan:
{code:java}
public RelNode findBestExp() {
assert root != null;
executeProgram(mainProgram);
// Get rid of everything except what's in the final plan.
collectGarbage();
return buildFinalPlan(root);
}
{code}
And the union have large inputs, so the performance is poor(in
SetOp#replaceInput, we have to recomputeDigest ), we can skip buildFinalPlan if
the inputs are not changed
> skip HepPlanner#buildFinalPlan when there's no rule fired in the program
>
>
> Key: CALCITE-4578
> URL: https://issues.apache.org/jira/browse/CALCITE-4578
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Attachments: image-2021-04-11-17-42-38-595.png
>
>
> Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3,
> 'three')...(1, 'ten thousand');
> It generates a Union node with 1 inputs, and the performance is poor,
> here's the profile:
> !image-2021-04-11-17-42-38-595.png|width=1086,height=240!
> We create a program(HepProgram) to do the union merge, in this case, we only
> have one union, so the rule is not fired, but it will still build the
> buildFinalPlan, and AbstractRelNode#explain has performance issue in this
> case(see the flame graph):
> {code:java}
> public RelNode findBestExp() {
> assert root != null;
> executeProgram(mainProgram);
> // Get rid of everything except what's in the final plan.
> collectGarbage();
> return buildFinalPlan(root);
> }
> {code}
> And the union has large inputs, so the performance is poor(in
> SetOp#replaceInput, we have to recomputeDigest ), we can skip buildFinalPlan
> if there's no rule fired.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4578) skip HepPlanner#buildFinalPlan when there's no rule fired in the program
[
https://issues.apache.org/jira/browse/CALCITE-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiatao Tao updated CALCITE-4578:
Description:
Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3,
'three')...(1, 'ten thousand');
It generates a Union node with 1 inputs, and the performance is poor,
here's the profile:
!image-2021-04-11-17-42-38-595.png|width=1086,height=240!
We create a program(HepProgram) to do the union merge, in this case, we only
have one union, so the rule is not applied, but it will still build the
buildFinalPlan:
{code:java}
public RelNode findBestExp() {
assert root != null;
executeProgram(mainProgram);
// Get rid of everything except what's in the final plan.
collectGarbage();
return buildFinalPlan(root);
}
{code}
And the union have large inputs, so the performance is poor(in
SetOp#replaceInput, we have to recomputeDigest ), we can skip buildFinalPlan if
the inputs are not changed
was:
Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3,
'three')...(1, 'ten thousand');
It generates a Union node with 1 inputs, and the performance is poor,
here's the profile:
!image-2021-04-11-17-42-38-595.png|width=1086,height=240!
We create a program(HepProgram) to do the union merge, in this case, we only
have one union, so the rule is not applied, but it will still build the
buildFinalPlan:
{code:java}
public RelNode findBestExp() {
assert root != null;
executeProgram(mainProgram);
// Get rid of everything except what's in the final plan.
collectGarbage();
return buildFinalPlan(root);
}
{code}
And the union have large inputs, so the performance is poor(in
SetOp#replaceInput, we have to recomputeDigest ), we can skip recomputeDigest
if the inputs are not changed
> skip HepPlanner#buildFinalPlan when there's no rule fired in the program
>
>
> Key: CALCITE-4578
> URL: https://issues.apache.org/jira/browse/CALCITE-4578
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Attachments: image-2021-04-11-17-42-38-595.png
>
>
> Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3,
> 'three')...(1, 'ten thousand');
> It generates a Union node with 1 inputs, and the performance is poor,
> here's the profile:
> !image-2021-04-11-17-42-38-595.png|width=1086,height=240!
> We create a program(HepProgram) to do the union merge, in this case, we only
> have one union, so the rule is not applied, but it will still build the
> buildFinalPlan:
> {code:java}
> public RelNode findBestExp() {
> assert root != null;
> executeProgram(mainProgram);
> // Get rid of everything except what's in the final plan.
> collectGarbage();
> return buildFinalPlan(root);
> }
> {code}
> And the union have large inputs, so the performance is poor(in
> SetOp#replaceInput, we have to recomputeDigest ), we can skip buildFinalPlan
> if the inputs are not changed
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4578) skip HepPlanner#buildFinalPlan when there's no rule fired in the program
[
https://issues.apache.org/jira/browse/CALCITE-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiatao Tao updated CALCITE-4578:
Summary: skip HepPlanner#buildFinalPlan when there's no rule fired in the
program (was: skip replaceInput when node's inputs are not changed)
> skip HepPlanner#buildFinalPlan when there's no rule fired in the program
>
>
> Key: CALCITE-4578
> URL: https://issues.apache.org/jira/browse/CALCITE-4578
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Attachments: image-2021-04-11-17-42-38-595.png
>
>
> Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3,
> 'three')...(1, 'ten thousand');
> It generates a Union node with 1 inputs, and the performance is poor,
> here's the profile:
> !image-2021-04-11-17-42-38-595.png|width=1086,height=240!
> We create a program(HepProgram) to do the union merge, in this case, we only
> have one union, so the rule is not applied, but it will still build the
> buildFinalPlan:
> {code:java}
> public RelNode findBestExp() {
> assert root != null;
> executeProgram(mainProgram);
> // Get rid of everything except what's in the final plan.
> collectGarbage();
> return buildFinalPlan(root);
> }
> {code}
> And the union have large inputs, so the performance is poor(in
> SetOp#replaceInput, we have to recomputeDigest ), we can skip recomputeDigest
> if the inputs are not changed
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4577) RelDigestWriter#done has performance when node's inputs is large
[
https://issues.apache.org/jira/browse/CALCITE-4577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiatao Tao updated CALCITE-4577:
Description:
Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3,
'three')...(1, 'ten thousand');
It generates a Union node with 1 inputs, and the performance is poor,
here's the profile:
!image-2021-04-11-16-53-58-757.png|width=735,height=109!
A point that affects performance is the array copy of StringBuilder, current we
just new StringBuilder with default capacity, my proposal is to consider the
node's input size, like that(we can discuss the strategy):
org.apache.calcite.rel.AbstractRelNode.RelDigestWriter#done
{code:java}
StringBuilder sb = new StringBuilder((values.size() + 1) * 16);{code}
It's about 20% performance improvement and mem is more smooth.
was:
Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3,
'three')...(1, 'ten thousand');
It generates a Union node with 1 inputs, and the performance is poor,
here's the profile:
!image-2021-04-11-16-53-35-466.png|width=740,height=185!
!image-2021-04-11-16-53-58-757.png|width=735,height=109!
A point that affects performance is the array copy of StringBuilder, current we
just new StringBuilder with default capacity, my proposal is to consider the
node's input size, like that(we can discuss the strategy):
org.apache.calcite.rel.AbstractRelNode.RelDigestWriter#done
{code:java}
StringBuilder sb = new StringBuilder((values.size() + 1) * 16);{code}
It's about 20% performance improvement and mem is more smooth.
> RelDigestWriter#done has performance when node's inputs is large
>
>
> Key: CALCITE-4577
> URL: https://issues.apache.org/jira/browse/CALCITE-4577
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Critical
> Attachments: image-2021-04-11-16-53-35-466.png,
> image-2021-04-11-16-53-58-757.png
>
>
> Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3,
> 'three')...(1, 'ten thousand');
> It generates a Union node with 1 inputs, and the performance is poor,
> here's the profile:
>
> !image-2021-04-11-16-53-58-757.png|width=735,height=109!
> A point that affects performance is the array copy of StringBuilder, current
> we just new StringBuilder with default capacity, my proposal is to consider
> the node's input size, like that(we can discuss the strategy):
> org.apache.calcite.rel.AbstractRelNode.RelDigestWriter#done
> {code:java}
> StringBuilder sb = new StringBuilder((values.size() + 1) * 16);{code}
> It's about 20% performance improvement and mem is more smooth.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4577) RelDigestWriter#done has performance issue when node's inputs is large
[
https://issues.apache.org/jira/browse/CALCITE-4577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiatao Tao updated CALCITE-4577:
Summary: RelDigestWriter#done has performance issue when node's inputs is
large (was: RelDigestWriter#done has performance issu when node's inputs is
large)
> RelDigestWriter#done has performance issue when node's inputs is large
> --
>
> Key: CALCITE-4577
> URL: https://issues.apache.org/jira/browse/CALCITE-4577
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Critical
> Attachments: image-2021-04-11-16-53-35-466.png,
> image-2021-04-11-16-53-58-757.png
>
>
> Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3,
> 'three')...(1, 'ten thousand');
> It generates a Union node with 1 inputs, and the performance is poor,
> here's the profile:
>
> !image-2021-04-11-16-53-58-757.png|width=735,height=109!
> A point that affects performance is the array copy of StringBuilder, current
> we just new StringBuilder with default capacity, my proposal is to consider
> the node's input size, like that(we can discuss the strategy):
> org.apache.calcite.rel.AbstractRelNode.RelDigestWriter#done
> {code:java}
> StringBuilder sb = new StringBuilder((values.size() + 1) * 16);{code}
> It's about 20% performance improvement and mem is more smooth.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4577) RelDigestWriter#done has performance issu when node's inputs is large
[
https://issues.apache.org/jira/browse/CALCITE-4577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiatao Tao updated CALCITE-4577:
Summary: RelDigestWriter#done has performance issu when node's inputs is
large (was: RelDigestWriter#done has performance when node's inputs is large)
> RelDigestWriter#done has performance issu when node's inputs is large
> -
>
> Key: CALCITE-4577
> URL: https://issues.apache.org/jira/browse/CALCITE-4577
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Critical
> Attachments: image-2021-04-11-16-53-35-466.png,
> image-2021-04-11-16-53-58-757.png
>
>
> Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3,
> 'three')...(1, 'ten thousand');
> It generates a Union node with 1 inputs, and the performance is poor,
> here's the profile:
>
> !image-2021-04-11-16-53-58-757.png|width=735,height=109!
> A point that affects performance is the array copy of StringBuilder, current
> we just new StringBuilder with default capacity, my proposal is to consider
> the node's input size, like that(we can discuss the strategy):
> org.apache.calcite.rel.AbstractRelNode.RelDigestWriter#done
> {code:java}
> StringBuilder sb = new StringBuilder((values.size() + 1) * 16);{code}
> It's about 20% performance improvement and mem is more smooth.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4578) skip replaceInput when node's inputs are not changed
[
https://issues.apache.org/jira/browse/CALCITE-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiatao Tao updated CALCITE-4578:
Description:
Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3,
'three')...(1, 'ten thousand');
It generates a Union node with 1 inputs, and the performance is poor,
here's the profile:
!image-2021-04-11-17-42-38-595.png|width=1086,height=240!
We create a program(HepProgram) to do the union merge, in this case, we only
have one union, so the rule is not applied, but it will still build the
buildFinalPlan:
{code:java}
public RelNode findBestExp() {
assert root != null;
executeProgram(mainProgram);
// Get rid of everything except what's in the final plan.
collectGarbage();
return buildFinalPlan(root);
}
{code}
And the union have large inputs, so the performance is poor(in
SetOp#replaceInput, we have to recomputeDigest ), we can skip recomputeDigest
if the inputs are not changed
was:
Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3,
'three')...(1, 'ten thousand');
It generates a Union node with 1 inputs, and the performance is poor,
here's the profile:
!image-2021-04-11-17-42-38-595.png|width=1086,height=240!
We create a program(HepProgram) to do the union merge, in this case, we only
have one union, so the rule is not applied, but it will still build the
buildFinalPlan:
{code:java}
public RelNode findBestExp() {
assert root != null;
executeProgram(mainProgram);
// Get rid of everything except what's in the final plan.
collectGarbage();
return buildFinalPlan(root);
}
{code}
And the union have large inputs, so the performance is poor(in
SetOp#replaceInput, we have to recomputeDigest ), we can skip recomputeDigest
if the inputs is not changed:
{code:java}
@Override public void replaceInput(int ordinalInParent, RelNode p) {
final List newInputs = new ArrayList<>(inputs);
newInputs.set(ordinalInParent, p);
if (!newInputs.equals(inputs)) {
inputs = ImmutableList.copyOf(newInputs);
recomputeDigest();
}
}
{code}
> skip replaceInput when node's inputs are not changed
>
>
> Key: CALCITE-4578
> URL: https://issues.apache.org/jira/browse/CALCITE-4578
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Attachments: image-2021-04-11-17-42-38-595.png
>
>
> Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3,
> 'three')...(1, 'ten thousand');
> It generates a Union node with 1 inputs, and the performance is poor,
> here's the profile:
> !image-2021-04-11-17-42-38-595.png|width=1086,height=240!
> We create a program(HepProgram) to do the union merge, in this case, we only
> have one union, so the rule is not applied, but it will still build the
> buildFinalPlan:
> {code:java}
> public RelNode findBestExp() {
> assert root != null;
> executeProgram(mainProgram);
> // Get rid of everything except what's in the final plan.
> collectGarbage();
> return buildFinalPlan(root);
> }
> {code}
> And the union have large inputs, so the performance is poor(in
> SetOp#replaceInput, we have to recomputeDigest ), we can skip recomputeDigest
> if the inputs are not changed
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4578) skip replaceInput when node's inputs are not changed
[
https://issues.apache.org/jira/browse/CALCITE-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiatao Tao updated CALCITE-4578:
Summary: skip replaceInput when node's inputs are not changed (was: skip
replaceInput when inputs are not changed)
> skip replaceInput when node's inputs are not changed
>
>
> Key: CALCITE-4578
> URL: https://issues.apache.org/jira/browse/CALCITE-4578
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Attachments: image-2021-04-11-17-42-38-595.png
>
>
> Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3,
> 'three')...(1, 'ten thousand');
> It generates a Union node with 1 inputs, and the performance is poor,
> here's the profile:
> !image-2021-04-11-17-42-38-595.png|width=1086,height=240!
> We create a program(HepProgram) to do the union merge, in this case, we only
> have one union, so the rule is not applied, but it will still build the
> buildFinalPlan:
> {code:java}
> public RelNode findBestExp() {
> assert root != null;
> executeProgram(mainProgram);
> // Get rid of everything except what's in the final plan.
> collectGarbage();
> return buildFinalPlan(root);
> }
> {code}
> And the union have large inputs, so the performance is poor(in
> SetOp#replaceInput, we have to recomputeDigest ), we can skip recomputeDigest
> if the inputs is not changed:
> {code:java}
> @Override public void replaceInput(int ordinalInParent, RelNode p) {
> final List newInputs = new ArrayList<>(inputs);
> newInputs.set(ordinalInParent, p);
> if (!newInputs.equals(inputs)) {
> inputs = ImmutableList.copyOf(newInputs);
> recomputeDigest();
> }
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4578) skip replaceInput when inputs are not changed
[
https://issues.apache.org/jira/browse/CALCITE-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiatao Tao updated CALCITE-4578:
Summary: skip replaceInput when inputs are not changed (was: skip
SetOp#replaceInput when inputs are not changed)
> skip replaceInput when inputs are not changed
> -
>
> Key: CALCITE-4578
> URL: https://issues.apache.org/jira/browse/CALCITE-4578
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Attachments: image-2021-04-11-17-42-38-595.png
>
>
> Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3,
> 'three')...(1, 'ten thousand');
> It generates a Union node with 1 inputs, and the performance is poor,
> here's the profile:
> !image-2021-04-11-17-42-38-595.png|width=1086,height=240!
> We create a program(HepProgram) to do the union merge, in this case, we only
> have one union, so the rule is not applied, but it will still build the
> buildFinalPlan:
> {code:java}
> public RelNode findBestExp() {
> assert root != null;
> executeProgram(mainProgram);
> // Get rid of everything except what's in the final plan.
> collectGarbage();
> return buildFinalPlan(root);
> }
> {code}
> And the union have large inputs, so the performance is poor(in
> SetOp#replaceInput, we have to recomputeDigest ), we can skip recomputeDigest
> if the inputs is not changed:
> {code:java}
> @Override public void replaceInput(int ordinalInParent, RelNode p) {
> final List newInputs = new ArrayList<>(inputs);
> newInputs.set(ordinalInParent, p);
> if (!newInputs.equals(inputs)) {
> inputs = ImmutableList.copyOf(newInputs);
> recomputeDigest();
> }
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4578) skip SetOp#replaceInput when inputs are not changed
[
https://issues.apache.org/jira/browse/CALCITE-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiatao Tao updated CALCITE-4578:
Description:
Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3,
'three')...(1, 'ten thousand');
It generates a Union node with 1 inputs, and the performance is poor,
here's the profile:
!image-2021-04-11-17-42-38-595.png|width=1086,height=240!
We create a program(HepProgram) to do the union merge, in this case, we only
have one union, so the rule is not applied, but it will still build the
buildFinalPlan:
{code:java}
public RelNode findBestExp() {
assert root != null;
executeProgram(mainProgram);
// Get rid of everything except what's in the final plan.
collectGarbage();
return buildFinalPlan(root);
}
{code}
And the union have large inputs, so the performance is poor(in
SetOp#replaceInput, we have to recomputeDigest ), we can skip recomputeDigest
if the inputs is not changed:
{code:java}
@Override public void replaceInput(int ordinalInParent, RelNode p) {
final List newInputs = new ArrayList<>(inputs);
newInputs.set(ordinalInParent, p);
if (!newInputs.equals(inputs)) {
inputs = ImmutableList.copyOf(newInputs);
recomputeDigest();
}
}
{code}
was:
Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3,
'three')...(1, 'ten thousand');
It generates a Union node with 1 inputs, and the performance is poor,
here's the profile:
!image-2021-04-11-17-42-38-595.png|width=1086,height=240!
We create a program(HepProgram) to do the union merge, in this case, we only
have one union, so the rule is not applied, but it will still build the
buildFinalPlan:
{code:java}
public RelNode findBestExp() {
assert root != null;
executeProgram(mainProgram);
// Get rid of everything except what's in the final plan.
collectGarbage();
return buildFinalPlan(root);
}
{code}
And the union have large inputs, so the performance is poor(in ), we can skip
> skip SetOp#replaceInput when inputs are not changed
> ---
>
> Key: CALCITE-4578
> URL: https://issues.apache.org/jira/browse/CALCITE-4578
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Attachments: image-2021-04-11-17-42-38-595.png
>
>
> Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3,
> 'three')...(1, 'ten thousand');
> It generates a Union node with 1 inputs, and the performance is poor,
> here's the profile:
> !image-2021-04-11-17-42-38-595.png|width=1086,height=240!
> We create a program(HepProgram) to do the union merge, in this case, we only
> have one union, so the rule is not applied, but it will still build the
> buildFinalPlan:
> {code:java}
> public RelNode findBestExp() {
> assert root != null;
> executeProgram(mainProgram);
> // Get rid of everything except what's in the final plan.
> collectGarbage();
> return buildFinalPlan(root);
> }
> {code}
> And the union have large inputs, so the performance is poor(in
> SetOp#replaceInput, we have to recomputeDigest ), we can skip recomputeDigest
> if the inputs is not changed:
> {code:java}
> @Override public void replaceInput(int ordinalInParent, RelNode p) {
> final List newInputs = new ArrayList<>(inputs);
> newInputs.set(ordinalInParent, p);
> if (!newInputs.equals(inputs)) {
> inputs = ImmutableList.copyOf(newInputs);
> recomputeDigest();
> }
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4578) skip SetOp#replaceInput when inputs are not changed
[
https://issues.apache.org/jira/browse/CALCITE-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiatao Tao updated CALCITE-4578:
Description:
Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3,
'three')...(1, 'ten thousand');
It generates a Union node with 1 inputs, and the performance is poor,
here's the profile:
!image-2021-04-11-17-42-38-595.png|width=1086,height=240!
We create a program(HepProgram) to do the union merge, in this case, we only
have one union, so the rule is not applied, but it will still build the
buildFinalPlan:
{code:java}
public RelNode findBestExp() {
assert root != null;
executeProgram(mainProgram);
// Get rid of everything except what's in the final plan.
collectGarbage();
return buildFinalPlan(root);
}
{code}
And the union have large inputs, so the performance is poor(in ), we can skip
was:
Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3,
'three')...(1, 'ten thousand');
It generates a Union node with 1 inputs, and the performance is poor,
here's the profile:
> skip SetOp#replaceInput when inputs are not changed
> ---
>
> Key: CALCITE-4578
> URL: https://issues.apache.org/jira/browse/CALCITE-4578
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Attachments: image-2021-04-11-17-42-38-595.png
>
>
> Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3,
> 'three')...(1, 'ten thousand');
> It generates a Union node with 1 inputs, and the performance is poor,
> here's the profile:
> !image-2021-04-11-17-42-38-595.png|width=1086,height=240!
> We create a program(HepProgram) to do the union merge, in this case, we only
> have one union, so the rule is not applied, but it will still build the
> buildFinalPlan:
> {code:java}
> public RelNode findBestExp() {
> assert root != null;
> executeProgram(mainProgram);
> // Get rid of everything except what's in the final plan.
> collectGarbage();
> return buildFinalPlan(root);
> }
> {code}
> And the union have large inputs, so the performance is poor(in ), we can skip
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4578) skip SetOp#replaceInput when inputs are not changed
[ https://issues.apache.org/jira/browse/CALCITE-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4578: Description: Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3, 'three')...(1, 'ten thousand'); It generates a Union node with 1 inputs, and the performance is poor, here's the profile: was: Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3, 'three')...(1, 'ten thousand'); It generates a Union node with 1 inputs, and the performance is poor, here's the profile: !image-2021-04-11-16-53-35-466.png|width=740,height=185! !image-2021-04-11-16-53-58-757.png|width=735,height=109! > skip SetOp#replaceInput when inputs are not changed > --- > > Key: CALCITE-4578 > URL: https://issues.apache.org/jira/browse/CALCITE-4578 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Major > Attachments: image-2021-04-11-17-42-38-595.png > > > Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3, > 'three')...(1, 'ten thousand'); > It generates a Union node with 1 inputs, and the performance is poor, > here's the profile: > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4578) skip SetOp#replaceInput when inputs are not changed
[ https://issues.apache.org/jira/browse/CALCITE-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4578: Attachment: image-2021-04-11-17-42-38-595.png > skip SetOp#replaceInput when inputs are not changed > --- > > Key: CALCITE-4578 > URL: https://issues.apache.org/jira/browse/CALCITE-4578 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Major > Attachments: image-2021-04-11-17-42-38-595.png > > > Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3, > 'three')...(1, 'ten thousand'); > It generates a Union node with 1 inputs, and the performance is poor, > here's the profile: > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4578) skip SetOp#replaceInput when inputs are not changed
[ https://issues.apache.org/jira/browse/CALCITE-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4578: Description: Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3, 'three')...(1, 'ten thousand'); It generates a Union node with 1 inputs, and the performance is poor, here's the profile: !image-2021-04-11-16-53-35-466.png|width=740,height=185! !image-2021-04-11-16-53-58-757.png|width=735,height=109! > skip SetOp#replaceInput when inputs are not changed > --- > > Key: CALCITE-4578 > URL: https://issues.apache.org/jira/browse/CALCITE-4578 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Major > > Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3, > 'three')...(1, 'ten thousand'); > It generates a Union node with 1 inputs, and the performance is poor, > here's the profile: > !image-2021-04-11-16-53-35-466.png|width=740,height=185! > !image-2021-04-11-16-53-58-757.png|width=735,height=109! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4578) skip SetOp#replaceInput when inputs are not changed
Jiatao Tao created CALCITE-4578: --- Summary: skip SetOp#replaceInput when inputs are not changed Key: CALCITE-4578 URL: https://issues.apache.org/jira/browse/CALCITE-4578 Project: Calcite Issue Type: Bug Components: core Reporter: Jiatao Tao Assignee: Jiatao Tao -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4577) RelDigestWriter#done has performance when node's inputs is large
[
https://issues.apache.org/jira/browse/CALCITE-4577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiatao Tao updated CALCITE-4577:
Description:
Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3,
'three')...(1, 'ten thousand');
It generates a Union node with 1 inputs, and the performance is poor,
here's the profile:
!image-2021-04-11-16-53-35-466.png|width=740,height=185!
!image-2021-04-11-16-53-58-757.png|width=735,height=109!
A point that affects performance is the array copy of StringBuilder, current we
just new StringBuilder with default capacity, my proposal is to consider the
node's input size, like that(we can discuss the strategy):
org.apache.calcite.rel.AbstractRelNode.RelDigestWriter#done
{code:java}
StringBuilder sb = new StringBuilder((values.size() + 1) * 16);{code}
It's about 20% performance improvement and mem is more smooth.
was:
Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3,
'three')...(1, 'ten thousand');
It generates a Union node with 1 inputs, and the performance is poor,
here's the profile:
!image-2021-04-11-16-53-35-466.png|width=740,height=185!
!image-2021-04-11-16-53-58-757.png|width=735,height=109!
A point that affects performance is the array copy of StringBuilder, current we
just new StringBuilder with default capacity, my proposal is to consider the
node's input size, like that(we can discuss the strategy):
org.apache.calcite.rel.AbstractRelNode.RelDigestWriter#done
{code:java}
StringBuilder sb = new StringBuilder((values.size() + 1) * 16);{code}
> RelDigestWriter#done has performance when node's inputs is large
>
>
> Key: CALCITE-4577
> URL: https://issues.apache.org/jira/browse/CALCITE-4577
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Critical
> Attachments: image-2021-04-11-16-53-35-466.png,
> image-2021-04-11-16-53-58-757.png
>
>
> Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3,
> 'three')...(1, 'ten thousand');
> It generates a Union node with 1 inputs, and the performance is poor,
> here's the profile:
> !image-2021-04-11-16-53-35-466.png|width=740,height=185!
> !image-2021-04-11-16-53-58-757.png|width=735,height=109!
> A point that affects performance is the array copy of StringBuilder, current
> we just new StringBuilder with default capacity, my proposal is to consider
> the node's input size, like that(we can discuss the strategy):
> org.apache.calcite.rel.AbstractRelNode.RelDigestWriter#done
> {code:java}
> StringBuilder sb = new StringBuilder((values.size() + 1) * 16);{code}
> It's about 20% performance improvement and mem is more smooth.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4577) RelDigestWriter#done has performance when node's inputs is large
[
https://issues.apache.org/jira/browse/CALCITE-4577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiatao Tao updated CALCITE-4577:
Description:
Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3,
'three')...(1, 'ten thousand');
It generates a Union node with 1 inputs, and the performance is poor,
here's the profile:
!image-2021-04-11-16-53-35-466.png|width=740,height=185!
!image-2021-04-11-16-53-58-757.png|width=735,height=109!
A point that affects performance is the array copy of StringBuilder, current we
just new StringBuilder with default capacity, my proposal is to consider the
node's input size, like that(we can discuss the strategy):
org.apache.calcite.rel.AbstractRelNode.RelDigestWriter#done
{code:java}
StringBuilder sb = new StringBuilder((values.size() + 1) * 16);{code}
was:
Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3,
'three')...(1, 'ten thousand');
It generate a Union node with 1 inputs, and the performance is poor, here's
the profile:
> RelDigestWriter#done has performance when node's inputs is large
>
>
> Key: CALCITE-4577
> URL: https://issues.apache.org/jira/browse/CALCITE-4577
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Critical
> Attachments: image-2021-04-11-16-53-35-466.png,
> image-2021-04-11-16-53-58-757.png
>
>
> Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3,
> 'three')...(1, 'ten thousand');
> It generates a Union node with 1 inputs, and the performance is poor,
> here's the profile:
> !image-2021-04-11-16-53-35-466.png|width=740,height=185!
> !image-2021-04-11-16-53-58-757.png|width=735,height=109!
> A point that affects performance is the array copy of StringBuilder, current
> we just new StringBuilder with default capacity, my proposal is to consider
> the node's input size, like that(we can discuss the strategy):
> org.apache.calcite.rel.AbstractRelNode.RelDigestWriter#done
> {code:java}
> StringBuilder sb = new StringBuilder((values.size() + 1) * 16);{code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4577) RelDigestWriter#done has performance when node's inputs is large
[ https://issues.apache.org/jira/browse/CALCITE-4577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4577: Attachment: image-2021-04-11-16-53-58-757.png > RelDigestWriter#done has performance when node's inputs is large > > > Key: CALCITE-4577 > URL: https://issues.apache.org/jira/browse/CALCITE-4577 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Critical > Attachments: image-2021-04-11-16-53-35-466.png, > image-2021-04-11-16-53-58-757.png > > > Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3, > 'three')...(1, 'ten thousand'); > It generate a Union node with 1 inputs, and the performance is poor, > here's the profile: > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4577) RelDigestWriter#done has performance when node's inputs is large
[ https://issues.apache.org/jira/browse/CALCITE-4577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4577: Attachment: (was: image-2021-04-11-16-53-16-374.png) > RelDigestWriter#done has performance when node's inputs is large > > > Key: CALCITE-4577 > URL: https://issues.apache.org/jira/browse/CALCITE-4577 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Critical > Attachments: image-2021-04-11-16-53-35-466.png > > > Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3, > 'three')...(1, 'ten thousand'); > It generate a Union node with 1 inputs, and the performance is poor, > here's the profile: > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4577) RelDigestWriter#done has performance when node's inputs is large
[ https://issues.apache.org/jira/browse/CALCITE-4577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4577: Attachment: image-2021-04-11-16-53-16-374.png > RelDigestWriter#done has performance when node's inputs is large > > > Key: CALCITE-4577 > URL: https://issues.apache.org/jira/browse/CALCITE-4577 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Critical > Attachments: image-2021-04-11-16-53-35-466.png > > > Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3, > 'three')...(1, 'ten thousand'); > It generate a Union node with 1 inputs, and the performance is poor, > here's the profile: > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4577) RelDigestWriter#done has performance when node's inputs is large
[ https://issues.apache.org/jira/browse/CALCITE-4577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4577: Attachment: image-2021-04-11-16-53-35-466.png > RelDigestWriter#done has performance when node's inputs is large > > > Key: CALCITE-4577 > URL: https://issues.apache.org/jira/browse/CALCITE-4577 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Critical > Attachments: image-2021-04-11-16-53-35-466.png > > > Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3, > 'three')...(1, 'ten thousand'); > It generate a Union node with 1 inputs, and the performance is poor, > here's the profile: > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4577) RelDigestWriter#done has performance when node's inputs is large
[ https://issues.apache.org/jira/browse/CALCITE-4577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4577: Description: Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3, 'three')...(1, 'ten thousand'); It generate a Union node with 1 inputs, and the performance is poor, here's the profile: > RelDigestWriter#done has performance when node's inputs is large > > > Key: CALCITE-4577 > URL: https://issues.apache.org/jira/browse/CALCITE-4577 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Critical > Attachments: image-2021-04-11-16-53-35-466.png > > > Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3, > 'three')...(1, 'ten thousand'); > It generate a Union node with 1 inputs, and the performance is poor, > here's the profile: > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4577) RelDigestWriter#done has performance when node's inputs is large
Jiatao Tao created CALCITE-4577: --- Summary: RelDigestWriter#done has performance when node's inputs is large Key: CALCITE-4577 URL: https://issues.apache.org/jira/browse/CALCITE-4577 Project: Calcite Issue Type: Bug Components: core Reporter: Jiatao Tao Assignee: Jiatao Tao -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-613) Implicitly convert character values in comparisons
[ https://issues.apache.org/jira/browse/CALCITE-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17290805#comment-17290805 ] Jiatao Tao commented on CALCITE-613: Is this a kind of TypeCoercion, should be controled by org.apache.calcite.sql.validate.SqlValidator#isTypeCoercionEnabled? > Implicitly convert character values in comparisons > -- > > Key: CALCITE-613 > URL: https://issues.apache.org/jira/browse/CALCITE-613 > Project: Calcite > Issue Type: Bug >Reporter: Sean Hsuan-Yi Chu >Assignee: Julian Hyde >Priority: Major > Fix For: 1.2.0-incubating > > > In relational DB such as Postgres, this query works fine. > "select ... from ... where column (INT type) between '10' and '11'" > Calcite blocks this query early by the fact that data types "char" & > "integer" are not directly compatible. However, this is very common for > people to filter columns with date types. For example, > "...where date between '1911-01-01' and '1911-01-02' " > To relax this type check when comparing with literals can help improve > usability. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4481) Replace some self-define methods with jdk methods in order to improve the readability
[ https://issues.apache.org/jira/browse/CALCITE-4481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17278642#comment-17278642 ] Jiatao Tao commented on CALCITE-4481: - +1 > Replace some self-define methods with jdk methods in order to improve the > readability > - > > Key: CALCITE-4481 > URL: https://issues.apache.org/jira/browse/CALCITE-4481 > Project: Calcite > Issue Type: Improvement >Reporter: dugenkui >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4482) "ImmutableBeans.create" has performance issue
[
https://issues.apache.org/jira/browse/CALCITE-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17278627#comment-17278627
]
Jiatao Tao edited comment on CALCITE-4482 at 2/4/21, 7:55 AM:
--
After the fix:
!image-2021-02-04-15-54-36-417.png|width=1207,height=874!
was (Author: aron.tao):
After the fix:
!image-2021-02-04-15-54-36-417.png!
> "ImmutableBeans.create" has performance issue
> -
>
> Key: CALCITE-4482
> URL: https://issues.apache.org/jira/browse/CALCITE-4482
> Project: Calcite
> Issue Type: Bug
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Attachments: image-2021-02-01-15-42-46-942.png,
> image-2021-02-01-15-45-11-863.png, image-2021-02-01-15-46-08-056.png,
> image-2021-02-01-15-47-31-577.png, image-2021-02-01-20-52-54-892.png,
> image-2021-02-04-15-54-36-417.png
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> We are doing the stressing test, and we found SqlNode#toString's time is
> unusually high, seems the call is all from SqlNode#toString, we can reduce
> the useless call of "ImmutableBeans.create" to reduce the time:
> My proposal is to extra default SqlWriterConfig to SqlNode and
> SqlNode#toString use this static field.
>
> {code:java}
> public static final SqlWriterConfig DEFAULT_SQL_WRITER_CONFIG =
> SqlPrettyWriter.config().withDialect(AnsiSqlDialect.DEFAULT)
> .withAlwaysUseParentheses(false)
> .withSelectListItemsOnSeparateLines(false)
> .withUpdateSetListNewline(false)
> .withIndentation(0);
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4482) "ImmutableBeans.create" has performance issue
[
https://issues.apache.org/jira/browse/CALCITE-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17278627#comment-17278627
]
Jiatao Tao edited comment on CALCITE-4482 at 2/4/21, 7:55 AM:
--
After the fix:
!image-2021-02-04-15-54-36-417.png|width=791,height=573!
was (Author: aron.tao):
After the fix:
!image-2021-02-04-15-54-36-417.png|width=1207,height=874!
> "ImmutableBeans.create" has performance issue
> -
>
> Key: CALCITE-4482
> URL: https://issues.apache.org/jira/browse/CALCITE-4482
> Project: Calcite
> Issue Type: Bug
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Attachments: image-2021-02-01-15-42-46-942.png,
> image-2021-02-01-15-45-11-863.png, image-2021-02-01-15-46-08-056.png,
> image-2021-02-01-15-47-31-577.png, image-2021-02-01-20-52-54-892.png,
> image-2021-02-04-15-54-36-417.png
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> We are doing the stressing test, and we found SqlNode#toString's time is
> unusually high, seems the call is all from SqlNode#toString, we can reduce
> the useless call of "ImmutableBeans.create" to reduce the time:
> My proposal is to extra default SqlWriterConfig to SqlNode and
> SqlNode#toString use this static field.
>
> {code:java}
> public static final SqlWriterConfig DEFAULT_SQL_WRITER_CONFIG =
> SqlPrettyWriter.config().withDialect(AnsiSqlDialect.DEFAULT)
> .withAlwaysUseParentheses(false)
> .withSelectListItemsOnSeparateLines(false)
> .withUpdateSetListNewline(false)
> .withIndentation(0);
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4482) "ImmutableBeans.create" has performance issue
[
https://issues.apache.org/jira/browse/CALCITE-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17278627#comment-17278627
]
Jiatao Tao edited comment on CALCITE-4482 at 2/4/21, 7:54 AM:
--
After the fix:
!image-2021-02-04-15-54-36-417.png!
was (Author: aron.tao):
After the fix:
!image-2021-02-04-15-53-52-594.png|width=1260,height=913!
> "ImmutableBeans.create" has performance issue
> -
>
> Key: CALCITE-4482
> URL: https://issues.apache.org/jira/browse/CALCITE-4482
> Project: Calcite
> Issue Type: Bug
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Attachments: image-2021-02-01-15-42-46-942.png,
> image-2021-02-01-15-45-11-863.png, image-2021-02-01-15-46-08-056.png,
> image-2021-02-01-15-47-31-577.png, image-2021-02-01-20-52-54-892.png,
> image-2021-02-04-15-54-36-417.png
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> We are doing the stressing test, and we found SqlNode#toString's time is
> unusually high, seems the call is all from SqlNode#toString, we can reduce
> the useless call of "ImmutableBeans.create" to reduce the time:
> My proposal is to extra default SqlWriterConfig to SqlNode and
> SqlNode#toString use this static field.
>
> {code:java}
> public static final SqlWriterConfig DEFAULT_SQL_WRITER_CONFIG =
> SqlPrettyWriter.config().withDialect(AnsiSqlDialect.DEFAULT)
> .withAlwaysUseParentheses(false)
> .withSelectListItemsOnSeparateLines(false)
> .withUpdateSetListNewline(false)
> .withIndentation(0);
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4482) "ImmutableBeans.create" has performance issue
[
https://issues.apache.org/jira/browse/CALCITE-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17278627#comment-17278627
]
Jiatao Tao commented on CALCITE-4482:
-
After the fix:
!image-2021-02-04-15-53-52-594.png|width=1260,height=913!
> "ImmutableBeans.create" has performance issue
> -
>
> Key: CALCITE-4482
> URL: https://issues.apache.org/jira/browse/CALCITE-4482
> Project: Calcite
> Issue Type: Bug
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Attachments: image-2021-02-01-15-42-46-942.png,
> image-2021-02-01-15-45-11-863.png, image-2021-02-01-15-46-08-056.png,
> image-2021-02-01-15-47-31-577.png, image-2021-02-01-20-52-54-892.png,
> image-2021-02-04-15-53-45-820.png, image-2021-02-04-15-53-52-594.png
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> We are doing the stressing test, and we found SqlNode#toString's time is
> unusually high, seems the call is all from SqlNode#toString, we can reduce
> the useless call of "ImmutableBeans.create" to reduce the time:
> My proposal is to extra default SqlWriterConfig to SqlNode and
> SqlNode#toString use this static field.
>
> {code:java}
> public static final SqlWriterConfig DEFAULT_SQL_WRITER_CONFIG =
> SqlPrettyWriter.config().withDialect(AnsiSqlDialect.DEFAULT)
> .withAlwaysUseParentheses(false)
> .withSelectListItemsOnSeparateLines(false)
> .withUpdateSetListNewline(false)
> .withIndentation(0);
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4482) "ImmutableBeans.create" has performance issue
[
https://issues.apache.org/jira/browse/CALCITE-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiatao Tao updated CALCITE-4482:
Attachment: (was: image-2021-02-04-15-53-45-820.png)
> "ImmutableBeans.create" has performance issue
> -
>
> Key: CALCITE-4482
> URL: https://issues.apache.org/jira/browse/CALCITE-4482
> Project: Calcite
> Issue Type: Bug
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Attachments: image-2021-02-01-15-42-46-942.png,
> image-2021-02-01-15-45-11-863.png, image-2021-02-01-15-46-08-056.png,
> image-2021-02-01-15-47-31-577.png, image-2021-02-01-20-52-54-892.png,
> image-2021-02-04-15-54-36-417.png
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> We are doing the stressing test, and we found SqlNode#toString's time is
> unusually high, seems the call is all from SqlNode#toString, we can reduce
> the useless call of "ImmutableBeans.create" to reduce the time:
> My proposal is to extra default SqlWriterConfig to SqlNode and
> SqlNode#toString use this static field.
>
> {code:java}
> public static final SqlWriterConfig DEFAULT_SQL_WRITER_CONFIG =
> SqlPrettyWriter.config().withDialect(AnsiSqlDialect.DEFAULT)
> .withAlwaysUseParentheses(false)
> .withSelectListItemsOnSeparateLines(false)
> .withUpdateSetListNewline(false)
> .withIndentation(0);
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4482) "ImmutableBeans.create" has performance issue
[
https://issues.apache.org/jira/browse/CALCITE-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiatao Tao updated CALCITE-4482:
Attachment: (was: image-2021-02-04-15-53-52-594.png)
> "ImmutableBeans.create" has performance issue
> -
>
> Key: CALCITE-4482
> URL: https://issues.apache.org/jira/browse/CALCITE-4482
> Project: Calcite
> Issue Type: Bug
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Attachments: image-2021-02-01-15-42-46-942.png,
> image-2021-02-01-15-45-11-863.png, image-2021-02-01-15-46-08-056.png,
> image-2021-02-01-15-47-31-577.png, image-2021-02-01-20-52-54-892.png,
> image-2021-02-04-15-54-36-417.png
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> We are doing the stressing test, and we found SqlNode#toString's time is
> unusually high, seems the call is all from SqlNode#toString, we can reduce
> the useless call of "ImmutableBeans.create" to reduce the time:
> My proposal is to extra default SqlWriterConfig to SqlNode and
> SqlNode#toString use this static field.
>
> {code:java}
> public static final SqlWriterConfig DEFAULT_SQL_WRITER_CONFIG =
> SqlPrettyWriter.config().withDialect(AnsiSqlDialect.DEFAULT)
> .withAlwaysUseParentheses(false)
> .withSelectListItemsOnSeparateLines(false)
> .withUpdateSetListNewline(false)
> .withIndentation(0);
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4482) "ImmutableBeans.create" has performance issue
[
https://issues.apache.org/jira/browse/CALCITE-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiatao Tao updated CALCITE-4482:
Attachment: (was: image-2021-02-04-15-53-51-142.png)
> "ImmutableBeans.create" has performance issue
> -
>
> Key: CALCITE-4482
> URL: https://issues.apache.org/jira/browse/CALCITE-4482
> Project: Calcite
> Issue Type: Bug
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Attachments: image-2021-02-01-15-42-46-942.png,
> image-2021-02-01-15-45-11-863.png, image-2021-02-01-15-46-08-056.png,
> image-2021-02-01-15-47-31-577.png, image-2021-02-01-20-52-54-892.png,
> image-2021-02-04-15-54-36-417.png
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> We are doing the stressing test, and we found SqlNode#toString's time is
> unusually high, seems the call is all from SqlNode#toString, we can reduce
> the useless call of "ImmutableBeans.create" to reduce the time:
> My proposal is to extra default SqlWriterConfig to SqlNode and
> SqlNode#toString use this static field.
>
> {code:java}
> public static final SqlWriterConfig DEFAULT_SQL_WRITER_CONFIG =
> SqlPrettyWriter.config().withDialect(AnsiSqlDialect.DEFAULT)
> .withAlwaysUseParentheses(false)
> .withSelectListItemsOnSeparateLines(false)
> .withUpdateSetListNewline(false)
> .withIndentation(0);
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4482) "ImmutableBeans.create" has performance issue
[
https://issues.apache.org/jira/browse/CALCITE-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiatao Tao updated CALCITE-4482:
Attachment: image-2021-02-04-15-53-51-142.png
> "ImmutableBeans.create" has performance issue
> -
>
> Key: CALCITE-4482
> URL: https://issues.apache.org/jira/browse/CALCITE-4482
> Project: Calcite
> Issue Type: Bug
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Attachments: image-2021-02-01-15-42-46-942.png,
> image-2021-02-01-15-45-11-863.png, image-2021-02-01-15-46-08-056.png,
> image-2021-02-01-15-47-31-577.png, image-2021-02-01-20-52-54-892.png,
> image-2021-02-04-15-54-36-417.png
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> We are doing the stressing test, and we found SqlNode#toString's time is
> unusually high, seems the call is all from SqlNode#toString, we can reduce
> the useless call of "ImmutableBeans.create" to reduce the time:
> My proposal is to extra default SqlWriterConfig to SqlNode and
> SqlNode#toString use this static field.
>
> {code:java}
> public static final SqlWriterConfig DEFAULT_SQL_WRITER_CONFIG =
> SqlPrettyWriter.config().withDialect(AnsiSqlDialect.DEFAULT)
> .withAlwaysUseParentheses(false)
> .withSelectListItemsOnSeparateLines(false)
> .withUpdateSetListNewline(false)
> .withIndentation(0);
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4482) "ImmutableBeans.create" has performance issue
[
https://issues.apache.org/jira/browse/CALCITE-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiatao Tao updated CALCITE-4482:
Attachment: image-2021-02-04-15-53-45-820.png
> "ImmutableBeans.create" has performance issue
> -
>
> Key: CALCITE-4482
> URL: https://issues.apache.org/jira/browse/CALCITE-4482
> Project: Calcite
> Issue Type: Bug
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Attachments: image-2021-02-01-15-42-46-942.png,
> image-2021-02-01-15-45-11-863.png, image-2021-02-01-15-46-08-056.png,
> image-2021-02-01-15-47-31-577.png, image-2021-02-01-20-52-54-892.png,
> image-2021-02-04-15-53-45-820.png, image-2021-02-04-15-53-52-594.png
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> We are doing the stressing test, and we found SqlNode#toString's time is
> unusually high, seems the call is all from SqlNode#toString, we can reduce
> the useless call of "ImmutableBeans.create" to reduce the time:
> My proposal is to extra default SqlWriterConfig to SqlNode and
> SqlNode#toString use this static field.
>
> {code:java}
> public static final SqlWriterConfig DEFAULT_SQL_WRITER_CONFIG =
> SqlPrettyWriter.config().withDialect(AnsiSqlDialect.DEFAULT)
> .withAlwaysUseParentheses(false)
> .withSelectListItemsOnSeparateLines(false)
> .withUpdateSetListNewline(false)
> .withIndentation(0);
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4482) "ImmutableBeans.create" has performance issue
[
https://issues.apache.org/jira/browse/CALCITE-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiatao Tao updated CALCITE-4482:
Attachment: image-2021-02-04-15-53-52-594.png
> "ImmutableBeans.create" has performance issue
> -
>
> Key: CALCITE-4482
> URL: https://issues.apache.org/jira/browse/CALCITE-4482
> Project: Calcite
> Issue Type: Bug
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Attachments: image-2021-02-01-15-42-46-942.png,
> image-2021-02-01-15-45-11-863.png, image-2021-02-01-15-46-08-056.png,
> image-2021-02-01-15-47-31-577.png, image-2021-02-01-20-52-54-892.png,
> image-2021-02-04-15-53-45-820.png, image-2021-02-04-15-53-52-594.png
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> We are doing the stressing test, and we found SqlNode#toString's time is
> unusually high, seems the call is all from SqlNode#toString, we can reduce
> the useless call of "ImmutableBeans.create" to reduce the time:
> My proposal is to extra default SqlWriterConfig to SqlNode and
> SqlNode#toString use this static field.
>
> {code:java}
> public static final SqlWriterConfig DEFAULT_SQL_WRITER_CONFIG =
> SqlPrettyWriter.config().withDialect(AnsiSqlDialect.DEFAULT)
> .withAlwaysUseParentheses(false)
> .withSelectListItemsOnSeparateLines(false)
> .withUpdateSetListNewline(false)
> .withIndentation(0);
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4482) "ImmutableBeans.create" has performance issue
[
https://issues.apache.org/jira/browse/CALCITE-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17276807#comment-17276807
]
Jiatao Tao commented on CALCITE-4482:
-
Thanks, I'll pull my request soon~
> "ImmutableBeans.create" has performance issue
> -
>
> Key: CALCITE-4482
> URL: https://issues.apache.org/jira/browse/CALCITE-4482
> Project: Calcite
> Issue Type: Bug
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Attachments: image-2021-02-01-15-42-46-942.png,
> image-2021-02-01-15-45-11-863.png, image-2021-02-01-15-46-08-056.png,
> image-2021-02-01-15-47-31-577.png, image-2021-02-01-20-52-54-892.png
>
>
> We are doing the stressing test, and we found SqlNode#toString's time is
> unusually high, seems the call is all from SqlNode#toString, we can reduce
> the useless call of "ImmutableBeans.create" to reduce the time:
> My proposal is to extra default SqlWriterConfig to SqlNode and
> SqlNode#toString use this static field.
>
> {code:java}
> public static final SqlWriterConfig DEFAULT_SQL_WRITER_CONFIG =
> SqlPrettyWriter.config().withDialect(AnsiSqlDialect.DEFAULT)
> .withAlwaysUseParentheses(false)
> .withSelectListItemsOnSeparateLines(false)
> .withUpdateSetListNewline(false)
> .withIndentation(0);
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4482) "ImmutableBeans.create" has performance issue
[
https://issues.apache.org/jira/browse/CALCITE-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17276300#comment-17276300
]
Jiatao Tao edited comment on CALCITE-4482 at 2/1/21, 12:54 PM:
---
Yeah, from the succinct perspective, it's better to do this in SqlPrettyWriter;
do in SqlNode, we can save more CPU time cuz we don't do the lambda again and
again. But I think the cost is not so big so I'll do this in SqlPrettyWriter.
{code:java}
c -> c.withDialect(AnsiSqlDialect.DEFAULT)
.withAlwaysUseParentheses(false)
.withSelectListItemsOnSeparateLines(false)
.withUpdateSetListNewline(false)
.withIndentation(0);
{code}
!image-2021-02-01-20-52-54-892.png|width=1310,height=207!
was (Author: aron.tao):
Yeah, from the succinct perspective, it's better to do this in SqlPrettyWriter;
do in SqlNode, we can save more CPU time cuz we don't do the lambda again and
again. But I think the cost is not so big so I'll do this in SqlPrettyWriter.
c -> c.withDialect(AnsiSqlDialect.DEFAULT)
.withAlwaysUseParentheses(false)
.withSelectListItemsOnSeparateLines(false)
.withUpdateSetListNewline(false)
.withIndentation(0);
!image-2021-02-01-20-52-54-892.png|width=1310,height=207!
> "ImmutableBeans.create" has performance issue
> -
>
> Key: CALCITE-4482
> URL: https://issues.apache.org/jira/browse/CALCITE-4482
> Project: Calcite
> Issue Type: Bug
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Attachments: image-2021-02-01-15-42-46-942.png,
> image-2021-02-01-15-45-11-863.png, image-2021-02-01-15-46-08-056.png,
> image-2021-02-01-15-47-31-577.png, image-2021-02-01-20-52-54-892.png
>
>
> We are doing the stressing test, and we found SqlNode#toString's time is
> unusually high, seems the call is all from SqlNode#toString, we can reduce
> the useless call of "ImmutableBeans.create" to reduce the time:
> My proposal is to extra default SqlWriterConfig to SqlNode and
> SqlNode#toString use this static field.
>
> {code:java}
> public static final SqlWriterConfig DEFAULT_SQL_WRITER_CONFIG =
> SqlPrettyWriter.config().withDialect(AnsiSqlDialect.DEFAULT)
> .withAlwaysUseParentheses(false)
> .withSelectListItemsOnSeparateLines(false)
> .withUpdateSetListNewline(false)
> .withIndentation(0);
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4482) "ImmutableBeans.create" has performance issue
[
https://issues.apache.org/jira/browse/CALCITE-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17276300#comment-17276300
]
Jiatao Tao commented on CALCITE-4482:
-
Yeah, from the succinct perspective, it's better to do this in SqlPrettyWriter;
do in SqlNode, we can save more CPU time cuz we don't do the lambda again and
again. But I think the cost is not so big so I'll do this in SqlPrettyWriter.
c -> c.withDialect(AnsiSqlDialect.DEFAULT)
.withAlwaysUseParentheses(false)
.withSelectListItemsOnSeparateLines(false)
.withUpdateSetListNewline(false)
.withIndentation(0);
!image-2021-02-01-20-52-54-892.png|width=1310,height=207!
> "ImmutableBeans.create" has performance issue
> -
>
> Key: CALCITE-4482
> URL: https://issues.apache.org/jira/browse/CALCITE-4482
> Project: Calcite
> Issue Type: Bug
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Attachments: image-2021-02-01-15-42-46-942.png,
> image-2021-02-01-15-45-11-863.png, image-2021-02-01-15-46-08-056.png,
> image-2021-02-01-15-47-31-577.png, image-2021-02-01-20-52-54-892.png
>
>
> We are doing the stressing test, and we found SqlNode#toString's time is
> unusually high, seems the call is all from SqlNode#toString, we can reduce
> the useless call of "ImmutableBeans.create" to reduce the time:
> My proposal is to extra default SqlWriterConfig to SqlNode and
> SqlNode#toString use this static field.
>
> {code:java}
> public static final SqlWriterConfig DEFAULT_SQL_WRITER_CONFIG =
> SqlPrettyWriter.config().withDialect(AnsiSqlDialect.DEFAULT)
> .withAlwaysUseParentheses(false)
> .withSelectListItemsOnSeparateLines(false)
> .withUpdateSetListNewline(false)
> .withIndentation(0);
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4482) "ImmutableBeans.create" has performance issue
[
https://issues.apache.org/jira/browse/CALCITE-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiatao Tao updated CALCITE-4482:
Attachment: image-2021-02-01-20-52-54-892.png
> "ImmutableBeans.create" has performance issue
> -
>
> Key: CALCITE-4482
> URL: https://issues.apache.org/jira/browse/CALCITE-4482
> Project: Calcite
> Issue Type: Bug
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Attachments: image-2021-02-01-15-42-46-942.png,
> image-2021-02-01-15-45-11-863.png, image-2021-02-01-15-46-08-056.png,
> image-2021-02-01-15-47-31-577.png, image-2021-02-01-20-52-54-892.png
>
>
> We are doing the stressing test, and we found SqlNode#toString's time is
> unusually high, seems the call is all from SqlNode#toString, we can reduce
> the useless call of "ImmutableBeans.create" to reduce the time:
> My proposal is to extra default SqlWriterConfig to SqlNode and
> SqlNode#toString use this static field.
>
> {code:java}
> public static final SqlWriterConfig DEFAULT_SQL_WRITER_CONFIG =
> SqlPrettyWriter.config().withDialect(AnsiSqlDialect.DEFAULT)
> .withAlwaysUseParentheses(false)
> .withSelectListItemsOnSeparateLines(false)
> .withUpdateSetListNewline(false)
> .withIndentation(0);
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4482) "ImmutableBeans.create" has performance issue
[
https://issues.apache.org/jira/browse/CALCITE-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17276294#comment-17276294
]
Jiatao Tao commented on CALCITE-4482:
-
Hi [~julianhyde], in the frame, as you mentioned, are all used when
SqlToRelConverter.AggConverter initializing.
{code:java}
for (int i = 0; i < selectList.size(); i++) {
SqlNode selectItem = selectList.get(i);
String name = null;
if (SqlUtil.isCallTo(
selectItem,
SqlStdOperatorTable.AS)) {
final SqlCall call = (SqlCall) selectItem;
selectItem = call.operand(0);
name = call.operand(1).toString();
}
if (name == null) {
name = validator().deriveAlias(selectItem, i);
assert name != null : "alias must not be null for " + selectItem + ", i=" +
i;
}
nameMap.put(selectItem.toString(), name);
}
{code}
> "ImmutableBeans.create" has performance issue
> -
>
> Key: CALCITE-4482
> URL: https://issues.apache.org/jira/browse/CALCITE-4482
> Project: Calcite
> Issue Type: Bug
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Attachments: image-2021-02-01-15-42-46-942.png,
> image-2021-02-01-15-45-11-863.png, image-2021-02-01-15-46-08-056.png,
> image-2021-02-01-15-47-31-577.png
>
>
> We are doing the stressing test, and we found SqlNode#toString's time is
> unusually high, seems the call is all from SqlNode#toString, we can reduce
> the useless call of "ImmutableBeans.create" to reduce the time:
> My proposal is to extra default SqlWriterConfig to SqlNode and
> SqlNode#toString use this static field.
>
> {code:java}
> public static final SqlWriterConfig DEFAULT_SQL_WRITER_CONFIG =
> SqlPrettyWriter.config().withDialect(AnsiSqlDialect.DEFAULT)
> .withAlwaysUseParentheses(false)
> .withSelectListItemsOnSeparateLines(false)
> .withUpdateSetListNewline(false)
> .withIndentation(0);
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4482) "ImmutableBeans.create" has performance issue
[
https://issues.apache.org/jira/browse/CALCITE-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiatao Tao updated CALCITE-4482:
Description:
We are doing the stressing test, and we found SqlNode#toString's time is
unusually high, seems the call is all from SqlNode#toString, we can reduce the
useless call of "ImmutableBeans.create" to reduce the time:
My proposal is to extra default SqlWriterConfig to SqlNode and SqlNode#toString
use this static field.
{code:java}
public static final SqlWriterConfig DEFAULT_SQL_WRITER_CONFIG =
SqlPrettyWriter.config().withDialect(AnsiSqlDialect.DEFAULT)
.withAlwaysUseParentheses(false)
.withSelectListItemsOnSeparateLines(false)
.withUpdateSetListNewline(false)
.withIndentation(0);
{code}
was:
We are doing the stressing test, and we found SqlNode#toString's time is
unusually high, seems the call is all from SqlNode#toString, we can reduce the
useless call of "ImmutableBeans.create" to reduce the time:
My proposal is to extra default SqlWriterConfig to SqlNode and SqlNode#toString
use this static field.
{code:java}
public static final SqlWriterConfig defaultSqlWriterConfig =
SqlPrettyWriter.config().withDialect(AnsiSqlDialect.DEFAULT)
.withAlwaysUseParentheses(false)
.withSelectListItemsOnSeparateLines(false)
.withUpdateSetListNewline(false)
.withIndentation(0);
{code}
> "ImmutableBeans.create" has performance issue
> -
>
> Key: CALCITE-4482
> URL: https://issues.apache.org/jira/browse/CALCITE-4482
> Project: Calcite
> Issue Type: Bug
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Attachments: image-2021-02-01-15-42-46-942.png,
> image-2021-02-01-15-45-11-863.png, image-2021-02-01-15-46-08-056.png,
> image-2021-02-01-15-47-31-577.png
>
>
> We are doing the stressing test, and we found SqlNode#toString's time is
> unusually high, seems the call is all from SqlNode#toString, we can reduce
> the useless call of "ImmutableBeans.create" to reduce the time:
> My proposal is to extra default SqlWriterConfig to SqlNode and
> SqlNode#toString use this static field.
>
> {code:java}
> public static final SqlWriterConfig DEFAULT_SQL_WRITER_CONFIG =
> SqlPrettyWriter.config().withDialect(AnsiSqlDialect.DEFAULT)
> .withAlwaysUseParentheses(false)
> .withSelectListItemsOnSeparateLines(false)
> .withUpdateSetListNewline(false)
> .withIndentation(0);
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4482) "ImmutableBeans.create" has performance issue
[
https://issues.apache.org/jira/browse/CALCITE-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiatao Tao updated CALCITE-4482:
Description:
We are doing the stressing test, and we found SqlNode#toString's time is
unusually high, seems the call is all from SqlNode#toString, we can reduce the
useless call of "ImmutableBeans.create" to reduce the time:
My proposal is to extra default SqlWriterConfig to SqlNode and SqlNode#toString
use this static field.
{code:java}
public static final SqlWriterConfig defaultSqlWriterConfig =
SqlPrettyWriter.config().withDialect(AnsiSqlDialect.DEFAULT)
.withAlwaysUseParentheses(false)
.withSelectListItemsOnSeparateLines(false)
.withUpdateSetListNewline(false)
.withIndentation(0);
{code}
> "ImmutableBeans.create" has performance issue
> -
>
> Key: CALCITE-4482
> URL: https://issues.apache.org/jira/browse/CALCITE-4482
> Project: Calcite
> Issue Type: Bug
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Attachments: image-2021-02-01-15-42-46-942.png,
> image-2021-02-01-15-45-11-863.png, image-2021-02-01-15-46-08-056.png,
> image-2021-02-01-15-47-31-577.png
>
>
> We are doing the stressing test, and we found SqlNode#toString's time is
> unusually high, seems the call is all from SqlNode#toString, we can reduce
> the useless call of "ImmutableBeans.create" to reduce the time:
> My proposal is to extra default SqlWriterConfig to SqlNode and
> SqlNode#toString use this static field.
>
> {code:java}
> public static final SqlWriterConfig defaultSqlWriterConfig =
> SqlPrettyWriter.config().withDialect(AnsiSqlDialect.DEFAULT)
> .withAlwaysUseParentheses(false)
> .withSelectListItemsOnSeparateLines(false)
> .withUpdateSetListNewline(false)
> .withIndentation(0);
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4482) "ImmutableBeans.create" has performance issue
[ https://issues.apache.org/jira/browse/CALCITE-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17276111#comment-17276111 ] Jiatao Tao edited comment on CALCITE-4482 at 2/1/21, 7:48 AM: -- We are doing the stressing test, and we found SqlNode#toString's time is unusually high, seems the call is all from SqlNode#toString, we can reduce the useless call of "ImmutableBeans.create" to reduce the time: !image-2021-02-01-15-42-46-942.png|width=695,height=515! was (Author: aron.tao): We are doing the stressing test, and we found SqlNode#toString' time is unusually high, seem we can reduce the useless call of ImmutableBeans.create to reduce the time: !image-2021-02-01-15-42-46-942.png|width=695,height=515! > "ImmutableBeans.create" has performance issue > - > > Key: CALCITE-4482 > URL: https://issues.apache.org/jira/browse/CALCITE-4482 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Major > Attachments: image-2021-02-01-15-42-46-942.png, > image-2021-02-01-15-45-11-863.png, image-2021-02-01-15-46-08-056.png, > image-2021-02-01-15-47-31-577.png > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4482) "ImmutableBeans.create" has performance issue
[ https://issues.apache.org/jira/browse/CALCITE-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4482: Attachment: image-2021-02-01-15-47-31-577.png > "ImmutableBeans.create" has performance issue > - > > Key: CALCITE-4482 > URL: https://issues.apache.org/jira/browse/CALCITE-4482 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Major > Attachments: image-2021-02-01-15-42-46-942.png, > image-2021-02-01-15-45-11-863.png, image-2021-02-01-15-46-08-056.png, > image-2021-02-01-15-47-31-577.png > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4482) "ImmutableBeans.create" has performance issue
[ https://issues.apache.org/jira/browse/CALCITE-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17276113#comment-17276113 ] Jiatao Tao commented on CALCITE-4482: - !image-2021-02-01-15-45-11-863.png|width=746,height=462! !image-2021-02-01-15-46-08-056.png|width=773,height=517! !image-2021-02-01-15-47-31-577.png|width=774,height=569! > "ImmutableBeans.create" has performance issue > - > > Key: CALCITE-4482 > URL: https://issues.apache.org/jira/browse/CALCITE-4482 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Major > Attachments: image-2021-02-01-15-42-46-942.png, > image-2021-02-01-15-45-11-863.png, image-2021-02-01-15-46-08-056.png, > image-2021-02-01-15-47-31-577.png > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4482) "ImmutableBeans.create" has performance issue
[ https://issues.apache.org/jira/browse/CALCITE-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4482: Attachment: image-2021-02-01-15-46-08-056.png > "ImmutableBeans.create" has performance issue > - > > Key: CALCITE-4482 > URL: https://issues.apache.org/jira/browse/CALCITE-4482 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Major > Attachments: image-2021-02-01-15-42-46-942.png, > image-2021-02-01-15-45-11-863.png, image-2021-02-01-15-46-08-056.png > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4482) "ImmutableBeans.create" has performance issue
[ https://issues.apache.org/jira/browse/CALCITE-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17276111#comment-17276111 ] Jiatao Tao commented on CALCITE-4482: - We are doing the stressing test, and we found SqlNode#toString' time is unusually high, seem we can reduce the useless call of ImmutableBeans.create to reduce the time: !image-2021-02-01-15-42-46-942.png|width=695,height=515! > "ImmutableBeans.create" has performance issue > - > > Key: CALCITE-4482 > URL: https://issues.apache.org/jira/browse/CALCITE-4482 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Major > Attachments: image-2021-02-01-15-42-46-942.png > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4482) "ImmutableBeans.create" has performance issue
[ https://issues.apache.org/jira/browse/CALCITE-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4482: Attachment: image-2021-02-01-15-45-11-863.png > "ImmutableBeans.create" has performance issue > - > > Key: CALCITE-4482 > URL: https://issues.apache.org/jira/browse/CALCITE-4482 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Major > Attachments: image-2021-02-01-15-42-46-942.png, > image-2021-02-01-15-45-11-863.png > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4482) "ImmutableBeans.create" has performance issue
[ https://issues.apache.org/jira/browse/CALCITE-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4482: Attachment: (was: image-2021-02-01-15-42-26-252.png) > "ImmutableBeans.create" has performance issue > - > > Key: CALCITE-4482 > URL: https://issues.apache.org/jira/browse/CALCITE-4482 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Major > Attachments: image-2021-02-01-15-42-46-942.png > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4482) "ImmutableBeans.create" has performance issue
[ https://issues.apache.org/jira/browse/CALCITE-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4482: Attachment: image-2021-02-01-15-42-46-942.png > "ImmutableBeans.create" has performance issue > - > > Key: CALCITE-4482 > URL: https://issues.apache.org/jira/browse/CALCITE-4482 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Major > Attachments: image-2021-02-01-15-42-46-942.png > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4482) "ImmutableBeans.create" has performance issue
[ https://issues.apache.org/jira/browse/CALCITE-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiatao Tao updated CALCITE-4482: Attachment: image-2021-02-01-15-42-26-252.png > "ImmutableBeans.create" has performance issue > - > > Key: CALCITE-4482 > URL: https://issues.apache.org/jira/browse/CALCITE-4482 > Project: Calcite > Issue Type: Bug >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Major > Attachments: image-2021-02-01-15-42-46-942.png > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4482) "ImmutableBeans.create" has performance issue
Jiatao Tao created CALCITE-4482: --- Summary: "ImmutableBeans.create" has performance issue Key: CALCITE-4482 URL: https://issues.apache.org/jira/browse/CALCITE-4482 Project: Calcite Issue Type: Bug Reporter: Jiatao Tao Assignee: Jiatao Tao -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4458) The "rowTypeCoercion" for "SET" operations should be "or" relationship
[
https://issues.apache.org/jira/browse/CALCITE-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiatao Tao updated CALCITE-4458:
Description:
In
org.apache.calcite.sql.validate.implicit.TypeCoercionImpl#rowTypeCoercion#124:
{code:java}
case UNION:
case INTERSECT:
case EXCEPT:
// Set operations are binary for now.
final SqlCall operand0 = ((SqlCall) query).operand(0);
final SqlCall operand1 = ((SqlCall) query).operand(1);
final boolean coerced = rowTypeCoercion(scope, operand0, columnIndex,
targetType)
&& rowTypeCoercion(scope, operand1, columnIndex, targetType);
{code}
Seems the coerced should be "||", not "&&"
was:
In
org.apache.calcite.sql.validate.implicit.TypeCoercionImpl#rowTypeCoercion#124:
{code:java}
case UNION:
case INTERSECT:
case EXCEPT:
// Set operations are binary for now.
final SqlCall operand0 = ((SqlCall) query).operand(0);
final SqlCall operand1 = ((SqlCall) query).operand(1);
final boolean coerced = rowTypeCoercion(scope, operand0, columnIndex,
targetType)
&& rowTypeCoercion(scope, operand1, columnIndex, targetType);
{code}
Seems the coerced should
> The "rowTypeCoercion" for "SET" operations should be "or" relationship
> --
>
> Key: CALCITE-4458
> URL: https://issues.apache.org/jira/browse/CALCITE-4458
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Critical
>
> In
> org.apache.calcite.sql.validate.implicit.TypeCoercionImpl#rowTypeCoercion#124:
> {code:java}
> case UNION:
> case INTERSECT:
> case EXCEPT:
> // Set operations are binary for now.
> final SqlCall operand0 = ((SqlCall) query).operand(0);
> final SqlCall operand1 = ((SqlCall) query).operand(1);
> final boolean coerced = rowTypeCoercion(scope, operand0, columnIndex,
> targetType)
> && rowTypeCoercion(scope, operand1, columnIndex, targetType);
> {code}
> Seems the coerced should be "||", not "&&"
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4458) "rowTypeCoercion" for "SET" operations should be or relationship
[
https://issues.apache.org/jira/browse/CALCITE-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiatao Tao updated CALCITE-4458:
Description:
In
org.apache.calcite.sql.validate.implicit.TypeCoercionImpl#rowTypeCoercion#124:
{code:java}
case UNION:
case INTERSECT:
case EXCEPT:
// Set operations are binary for now.
final SqlCall operand0 = ((SqlCall) query).operand(0);
final SqlCall operand1 = ((SqlCall) query).operand(1);
final boolean coerced = rowTypeCoercion(scope, operand0, columnIndex,
targetType)
&& rowTypeCoercion(scope, operand1, columnIndex, targetType);
{code}
Seems the coerced should
> "rowTypeCoercion" for "SET" operations should be or relationship
>
>
> Key: CALCITE-4458
> URL: https://issues.apache.org/jira/browse/CALCITE-4458
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Critical
>
> In
> org.apache.calcite.sql.validate.implicit.TypeCoercionImpl#rowTypeCoercion#124:
> {code:java}
> case UNION:
> case INTERSECT:
> case EXCEPT:
> // Set operations are binary for now.
> final SqlCall operand0 = ((SqlCall) query).operand(0);
> final SqlCall operand1 = ((SqlCall) query).operand(1);
> final boolean coerced = rowTypeCoercion(scope, operand0, columnIndex,
> targetType)
> && rowTypeCoercion(scope, operand1, columnIndex, targetType);
> {code}
> Seems the coerced should
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4458) The "rowTypeCoercion" for "SET" operations should be "or" relationship
[
https://issues.apache.org/jira/browse/CALCITE-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiatao Tao updated CALCITE-4458:
Summary: The "rowTypeCoercion" for "SET" operations should be "or"
relationship (was: "rowTypeCoercion" for "SET" operations should be or
relationship)
> The "rowTypeCoercion" for "SET" operations should be "or" relationship
> --
>
> Key: CALCITE-4458
> URL: https://issues.apache.org/jira/browse/CALCITE-4458
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Critical
>
> In
> org.apache.calcite.sql.validate.implicit.TypeCoercionImpl#rowTypeCoercion#124:
> {code:java}
> case UNION:
> case INTERSECT:
> case EXCEPT:
> // Set operations are binary for now.
> final SqlCall operand0 = ((SqlCall) query).operand(0);
> final SqlCall operand1 = ((SqlCall) query).operand(1);
> final boolean coerced = rowTypeCoercion(scope, operand0, columnIndex,
> targetType)
> && rowTypeCoercion(scope, operand1, columnIndex, targetType);
> {code}
> Seems the coerced should
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4458) "rowTypeCoercion" for "SET" operations should be or relationship
Jiatao Tao created CALCITE-4458: --- Summary: "rowTypeCoercion" for "SET" operations should be or relationship Key: CALCITE-4458 URL: https://issues.apache.org/jira/browse/CALCITE-4458 Project: Calcite Issue Type: Bug Components: core Reporter: Jiatao Tao Assignee: Jiatao Tao -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4424) Complete non-deterministic function in SqlFunction
[
https://issues.apache.org/jira/browse/CALCITE-4424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17252300#comment-17252300
]
Jiatao Tao edited comment on CALCITE-4424 at 12/24/20, 3:13 AM:
Hi [~julianhyde], what I mean is that I think they are
orthogonal(isDeterministic/isDynamicFunction).
{code:java}
* Returns whether it is unsafe to cache query plans referencing this
* operator; false is assumed by default
{code}
The isDynamicFunction's def is pretty clear, where to use is clear, it's an
independent interface, I think they have no relationship, so this Jira will not
care about isDynamicFunction.
was (Author: aron.tao):
Hi [~julianhyde], what I mean is that I think they are
orthogonal(isDeterministic/isDynamicFunction).
{code:java}
* Returns whether it is unsafe to cache query plans referencing this
* operator; false is assumed by default
{code}
The isDynamicFunction's def is pretty clear, where to use is clear, I think
they have no relationship, so this Jira will not care about isDynamicFunction.
> Complete non-deterministic function in SqlFunction
> --
>
> Key: CALCITE-4424
> URL: https://issues.apache.org/jira/browse/CALCITE-4424
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Current only SqlSequenceValueOperator override isDeterministic, func like
> RAND doesn't override isDeterministic
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4424) Complete non-deterministic function in SqlFunction
[
https://issues.apache.org/jira/browse/CALCITE-4424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17252300#comment-17252300
]
Jiatao Tao edited comment on CALCITE-4424 at 12/20/20, 3:30 AM:
Hi [~julianhyde], what I mean is that I think they are
orthogonal(isDeterministic/isDynamicFunction).
{code:java}
* Returns whether it is unsafe to cache query plans referencing this
* operator; false is assumed by default
{code}
The isDynamicFunction's def is pretty clear, where to use is clear, I think
they have no relationship, so this Jira will not care about isDynamicFunction.
was (Author: aron.tao):
Hi [~julianhyde], what I mean is that I think they are
orthogonal(isDeterministic/isDynamicFunction).
{code:java}
* Returns whether it is unsafe to cache query plans referencing this
* operator; false is assumed by default
{code}
The isDynamicFunction's def is pretty clear, I think they have no relationship,
so this Jira will not care about isDynamicFunction.
> Complete non-deterministic function in SqlFunction
> --
>
> Key: CALCITE-4424
> URL: https://issues.apache.org/jira/browse/CALCITE-4424
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Current only SqlSequenceValueOperator override isDeterministic, func like
> RAND doesn't override isDeterministic
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4424) Complete non-deterministic function in SqlFunction
[
https://issues.apache.org/jira/browse/CALCITE-4424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17252300#comment-17252300
]
Jiatao Tao edited comment on CALCITE-4424 at 12/20/20, 3:28 AM:
Hi [~julianhyde], what I mean is that I think they are
orthogonal(isDeterministic/isDynamicFunction).
{code:java}
* Returns whether it is unsafe to cache query plans referencing this
* operator; false is assumed by default
{code}
The isDynamicFunction's def is pretty clear, I think they have no relationship,
so this Jira will not care about isDynamicFunction.
was (Author: aron.tao):
Hi [~julianhyde], what I mean is that I think they are
orthogonal(isDeterministic/isDynamicFunction), so this Jira will not care about
isDynamicFunction. They have no relationship.
> Complete non-deterministic function in SqlFunction
> --
>
> Key: CALCITE-4424
> URL: https://issues.apache.org/jira/browse/CALCITE-4424
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Current only SqlSequenceValueOperator override isDeterministic, func like
> RAND doesn't override isDeterministic
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4424) Complete non-deterministic function in SqlFunction
[ https://issues.apache.org/jira/browse/CALCITE-4424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17252300#comment-17252300 ] Jiatao Tao commented on CALCITE-4424: - Hi [~julianhyde], what I mean is that I think they are orthogonal(isDeterministic/isDynamicFunction), so this Jira will not care about isDynamicFunction. They have no relationship. > Complete non-deterministic function in SqlFunction > -- > > Key: CALCITE-4424 > URL: https://issues.apache.org/jira/browse/CALCITE-4424 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > Current only SqlSequenceValueOperator override isDeterministic, func like > RAND doesn't override isDeterministic > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4424) Complete non-deterministic function in SqlFunction
[ https://issues.apache.org/jira/browse/CALCITE-4424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17250986#comment-17250986 ] Jiatao Tao edited comment on CALCITE-4424 at 12/20/20, 3:24 AM: Hi [~julianhyde], I think they are orthogonal, so answer point2, I would not change that. Func like CURRENT_DATE/CURRENT_TIMESTAMPE, I think it doesn't matter to determine them deterministic or non-deterministic, cuz current we do not observe that they will affect the optimized result(but rand will). So we just defined by our own standards, IMO we can define them as deterministic. was (Author: aron.tao): Hi [~julianhyde], in fact, I'm also confused about the concept of dynamic functions. But I think they are orthogonal, so answer point2, I would not change that. Func like CURRENT_DATE/CURRENT_TIMESTAMPE, I think it doesn't matter to determine them deterministic or non-deterministic, cuz current we do not observe that they will affect the optimized result(but rand will). So we just defined by our own standards, IMO we can define them as deterministic. > Complete non-deterministic function in SqlFunction > -- > > Key: CALCITE-4424 > URL: https://issues.apache.org/jira/browse/CALCITE-4424 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > Current only SqlSequenceValueOperator override isDeterministic, func like > RAND doesn't override isDeterministic > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
