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

BSE-4460: Calcite 1.38 #148

Merged
merged 40 commits into from
Jan 27, 2025
Merged

BSE-4460: Calcite 1.38 #148

merged 40 commits into from
Jan 27, 2025

Conversation

IsaacWarren
Copy link
Contributor

Changes included in this PR

Upgrade Calcite to 1.38

New rule CoreRules.PROJECT_OVER_SUM_TO_SUM0_RULE

Questions/request for close review

  • RexLiteral around line 1145
  • RexSimplify around line 2331 do we still need this Bodo change?
  • SqlValidatorImpl does the new getFieldAliases function do what our addition at line 600 was doing?

Testing strategy

CI

User facing changes

Checklist

  • Pipelines passed before requesting review. To run CI you must include [run CI] in your commit message.
  • I am familiar with the Contributing Guide
  • I have installed + ran pre-commit hooks.

Comments

RexShuttle, RexBuilder, RexWindow, SqlExtractFunction, SqlStdOperatorTable need re-indented

@@ -990,12 +991,25 @@ void propagateCostImprovements(RelNode rel) {
if (!relNode.getTraitSet().satisfies(subset.getTraitSet())) {
continue;
}
if (!cost.isLt(subset.bestCost)) {

// Update subset best and best's cost when we find a cheaper rel
Copy link
Contributor

Choose a reason for hiding this comment

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

It's possible this fixes an issue I found with cycles in the planner. However, I'm too afraid to try remove this, especially given our limited access to the customer tests, so can you open a backlog issue to investigate it?

Copy link
Contributor

Choose a reason for hiding this comment

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

Can you add the Bodo Change based on the diff? Its just for merge into but I was confused why we have this process.

/**
* <code>BITOR</code> scalar function.
*/
public static final SqlFunction BITOR =
Copy link
Contributor

Choose a reason for hiding this comment

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

Let's remove the bit function from our numeric operator table. Let's also open a backlog github issue to support the binary case for these.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Could you elaborate on this? All of the bit functions or just BITAND, BITOR, BITXOR, and BITNOT or the bitshift operations too? What do you mean by the binary case?

Copy link
Contributor

Choose a reason for hiding this comment

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

Let's see if we can remove coalesceCoercion.

* <p>Possible behavior differences include ignoring the {@code ORDER BY}
* clause of an embedded query, or converting measure expressions of a
* non-embedded query into values. */
@Value.Default default boolean embeddedQuery() {
Copy link
Contributor

Choose a reason for hiding this comment

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

Let's file an issue to explore this. We might have a simpler/better view expansion process now.

Copy link
Contributor

Choose a reason for hiding this comment

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

Let's add the bodo change here for fixing merge into.

Copy link
Contributor

Choose a reason for hiding this comment

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

It would be great if you could fix the formatting on this file because there are actually only a small number of changes.

@@ -461,6 +462,53 @@ public int getIntervalSign(String value) {
return sign;
}

public static TimeUnit stringToDatePartTimeUnit(String stringValue) {
Copy link
Contributor

Choose a reason for hiding this comment

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

How is this used? We may need to intercept the usage to ensure we have nanosecond handling.

@@ -720,7 +767,8 @@ private int[] evaluateIntervalLiteralAsQuarter(
BigDecimal month = quarter.multiply(MONTHS_IN_QUARTER);
Copy link
Contributor

Choose a reason for hiding this comment

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

Delete the Bodo Change. Its dead code now.

@@ -405,7 +408,7 @@ private RexNode simplifyGenericNode(RexCall e) {
return e;
}
// Bodo Change: Avoid passing the output type to allow deriving it.
return rexBuilder.makeCall(e.getOperator(), operands);
return rexBuilder.makeCall(e.getParserPosition(), e.getType(), e.getOperator(), operands);
Copy link
Contributor

Choose a reason for hiding this comment

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

This violates the Bodo change. I would revert passing e.getType()

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thank you!

final RexLiteral literal = comparison.literal;
final RexLiteral prevLiteral =
equalityConstantTerms.put(comparison.ref, literal);
// Bodo Change: literal.equals(prevLiteral) is not reliable because
Copy link
Contributor

Choose a reason for hiding this comment

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

If this merged into Calcite this seems good to me.

// which is not enough to exclude the literal. To be conservative we keep
// both checks and only convert to False if both fail.
if (!literal1.equals(literal2) && !literal1.getValue().equals(literal2.getValue())) {
if (literal1.getType().equals(literal2.getType()) && !literal1.equals(literal2)) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Same here.

@njriasan
Copy link
Contributor

Regarding Questions:

  1. I would keep the RexSimplify change. It looks good as shown.
  2. I think the RexLiteral changes are fine but we may need to check how it impacts our tests.
  3. For SqlValidatorImpl I'm not sure/I don't think so. We can hop on a call to ensure I know exactly which line matches.

Copy link

codecov bot commented Jan 16, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Please upload report for BASE (main@b585341). Learn more about missing BASE report.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #148   +/-   ##
=======================================
  Coverage        ?   77.78%           
=======================================
  Files           ?      169           
  Lines           ?    61952           
  Branches        ?     8671           
=======================================
  Hits            ?    48191           
  Misses          ?    11663           
  Partials        ?     2098           

@@ -1098,6 +1098,33 @@ SqlDrop SqlDropSchema(Span s) :
// AddExpression2b(ExprContext.ACCEPT_SUB_QUERY, list)
// }

//SqlNode DatePartFunctionCall() :
Copy link
Contributor

Choose a reason for hiding this comment

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

If you haven't already, I advise seeing if this branch causes anything in the test repo to fail / get changed (e.g. planner adjustments), and if so to open a parallel PR to update those.

@IsaacWarren IsaacWarren merged commit daf98a2 into main Jan 27, 2025
22 of 23 checks passed
@IsaacWarren IsaacWarren deleted the isaac/calcite_1.38 branch January 27, 2025 18:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants