Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CALCITE-4368] TopDownOptTest fails if applying non-substitution rule first #2237

Closed
wants to merge 2 commits into from

Conversation

chunweilei
Copy link
Contributor

@chunweilei chunweilei commented Oct 30, 2020

Usually O_INPUTS are only applied for groups with physical convention. But
when enabling AbstractConverter, the input of AbstractConverter might be
a group with NONE convention. In that case, no need to apply O_INPUTS.
Otherwise, it might throw an exception due to impossible transformation(
physical convention -> none convention).

Other change:

  • some cosmetic fix-ups
  • print the upper bound of the RelSubSet

@chunweilei chunweilei changed the title [CALCITE-4360] TopDownOptTest fails if applying non-substitution rule first [CALCITE-4368] TopDownOptTest fails if applying non-substitution rule first Oct 30, 2020
@chunweilei chunweilei added the LGTM-will-merge-soon Overall PR looks OK. Only minor things left. label Nov 2, 2020
@danny0405
Copy link
Contributor

Remember to update the commit message before commit.

@chunweilei
Copy link
Contributor Author

emember to update the commit message before commit.

Could you please tell me what I should update about the commit message? Thanks.

@chunweilei
Copy link
Contributor Author

Updated the commit message. Thank you for your suggestion, @danny0405 .

@vlsi
Copy link
Contributor

vlsi commented Nov 2, 2020

Frankly speaking, it is hard to review the change because there are lots of comment changes, and it is hard to spot code changes.

Please refrain from mixing unrelated comment changes and code changes into a single commit.

It does not mean I require that for this case, however, I opened this PR several times, and every time I thought it was javadoc-only change.

@vlsi
Copy link
Contributor

vlsi commented Nov 2, 2020

Could you please tell me what I should update about the commit message? Thanks

@chunweilei , could you please clarify what is the nature of the change?
Is it a cosmetic change?
Does this PR fix a bug?
Does this PR introduce a new feature?

The commit message says [CALCITE-4368] TopDownOptTest fails if applying non-substitution rule first, so the commit message suggests the change fixes a bug. However, the diff looks like a javadoc-only cosmetic change.

In case the PR is cosmetic, then the very same thing should be mentioned in the commit message. Otherwise, it is misleading, and it is time-consuming for the reviewers.

@vlsi vlsi removed the LGTM-will-merge-soon Overall PR looks OK. Only minor things left. label Nov 2, 2020
@chunweilei
Copy link
Contributor Author

@vlsi I have updated the commit message. This change not only fixes a bug but also have some fix-ups.

@chunweilei
Copy link
Contributor Author

chunweilei commented Nov 2, 2020

Frankly speaking, it is hard to review the change because there are lots of comment changes, and it is hard to spot code changes.

Please refrain from mixing unrelated comment changes and code changes into a single commit.

It does not mean I require that for this case, however, I opened this PR several times, and every time I thought it was javadoc-only change.

I don't want to see many commits that only have comment changes. It is not necessary. But I should have underlined the main change. Then it is much easier for reviewers.

@vlsi
Copy link
Contributor

vlsi commented Nov 2, 2020

@chunweilei, please split the change in two:

  • code change with the corresponding comments
  • other comment cleanups

Currently, it is hard to figure out where is the code part of the change.

@chunweilei
Copy link
Contributor Author

@vlsi
Copy link
Contributor

vlsi commented Nov 2, 2020

Please add tests to cover the change

@chunweilei
Copy link
Contributor Author

chunweilei commented Nov 2, 2020

Please add tests to cover the change

It's difficult to add a test to reproduce it. But you can reproduce it if you change the applying order of substitution rule and non-substitution rule. I described it in the jira case.

@vlsi
Copy link
Contributor

vlsi commented Nov 2, 2020

The main change is here: https://github.com/apache/calcite/pull/2237/files#diff-ad65441646b31d60e7a55d6bac2c1f4d9ddba3473b227963800b1b2bc292a319R342

It must come as its own commit. You should not require each and every reviewer to inspect the diff in order to find a single line change buried under lots of comment changes.

@vlsi vlsi added returned-with-feedback There are review comments (in JIRA and/or in GitHub) to be implemented before merging the PR tests-missing labels Nov 2, 2020
@chunweilei
Copy link
Contributor Author

It must come as its own commit. You should not require each and every reviewer to inspect the diff in order to find a single line change buried under lots of comment changes.

I do not require anything from anybody. It's just about preference. Does it really so difficult that someone has to spend hours on finding the main change? I don't think so. As you can see, two people have reviewed it at least and give their comments.

@chunweilei
Copy link
Contributor Author

chunweilei commented Nov 2, 2020

@chunweilei, please split the change in two:

  • code change with the corresponding comments
  • other comment cleanups

Currently, it is hard to figure out where is the code part of the change.

I am open to this change. Would split the change into two soon.

@chunweilei chunweilei removed the returned-with-feedback There are review comments (in JIRA and/or in GitHub) to be implemented before merging the PR label Nov 2, 2020
… first

Usually O_INPUTS are only applied for groups with physical convention. But
when enabling AbstractConverter, the input of AbstractConverter might be
a group with NONE convention. In that case, no need to apply O_INPUTS.
Otherwise, it might throw en exception due to impossible transformation(
physical convention -> none convention).
@chunweilei
Copy link
Contributor Author

@chunweilei, please split the change in two:

  • code change with the corresponding comments
  • other comment cleanups

Currently, it is hard to figure out where is the code part of the change.

I have split the change into two. Thank you for your suggestion.

@@ -335,6 +336,14 @@ default boolean onProduce(RelNode node) {
physicals.add(rel);
}
}

// No need to apply O_INPUTS if the group has not been implemented yet.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is O_INPUTS?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It means OptimzeInput, which is a term in Cascades planner. I borrow it from the comment[1].

[1] https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/plan/volcano/TopDownRuleDriver.java#L338

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see no reasons to invent obscure words when the thing can be explained in plain English.

Copy link
Contributor Author

@chunweilei chunweilei Nov 2, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would change it as you suggest. But the term O_INPUT is not invented currently. It comes from a classic paper[1] which was published in 1998.

image

[1] https://15721.courses.cs.cmu.edu/spring2019/papers/22-optimizer1/xu-columbia-thesis1998.pdf Page#63

@vlsi
Copy link
Contributor

vlsi commented Nov 2, 2020

have split the change into two

Thanks. It would be better if you specify the nature and the location of the change instead of the current Some cosmetic cleanup.
For instance: Fix grammar in Volcano planner comments

It's difficult to add a test to reproduce it. But you can reproduce it if you change the applying order of substitution rule and non-substitution rule.

If the bug happens only if you manually edit Calcite source, then why do you think it is a bug after all?

I described it in the jira case.

I do not see where CALCITE-4368 describes why test can't be added.

@vlsi vlsi added the returned-with-feedback There are review comments (in JIRA and/or in GitHub) to be implemented before merging the PR label Nov 2, 2020
@chunweilei
Copy link
Contributor Author

If the bug happens only if you manually edit Calcite source, then why do you think it is a bug after all?

  • It might happen in some cases. But I could not construct one currently.
  • Even though we change the order of the rule, the test cases should not fail. It is not expected.

@chunweilei
Copy link
Contributor Author

I do not see where CALCITE-4368 describes why test can't be added.

I mean I describe the way that reproduces the error in the JIRA case.

@vlsi
Copy link
Contributor

vlsi commented Nov 2, 2020

I'm inclined that this change must be accompanied by a test, otherwise, it should not be committed.

@chunweilei
Copy link
Contributor Author

I'm inclined that this change must be accompanied by a test, otherwise, it should not be committed.

As you insist, I would try my best to provide one.

@chunweilei
Copy link
Contributor Author

Opened another PR to fix comments: #2243.

@chunweilei
Copy link
Contributor Author

Close the PR since I can not reproduce it without changes.

@chunweilei chunweilei closed this Dec 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
returned-with-feedback There are review comments (in JIRA and/or in GitHub) to be implemented before merging the PR tests-missing
Projects
None yet
4 participants