[ESQL] Migrate SimplifyComparisonArithmetics optimization #109256
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
elasticsearchmachine
added
the
Team:Analytics
|
Pinging @elastic/es-analytical-engine (Team:Analytics) |
|
Hi @not-napoleon, I've created a changelog YAML for you. |
not-napoleon
commented
May 31, 2024
| import org.elasticsearch.xpack.esql.core.type.DataType; | ||
| import org.elasticsearch.xpack.esql.core.type.DataTypes; | ||
| import org.elasticsearch.xpack.esql.expression.predicate.operator.arithmetic.Neg; | ||
| import org.elasticsearch.xpack.esql.expression.predicate.operator.arithmetic.Sub; |
There was a problem hiding this comment.
Changing the Neg and Sub imports to point to the esql version, instead of the esql-core versions, resolves #108743
not-napoleon
commented
May 31, 2024
| final Expression apply() { | ||
| // force float point folding for FlP field | ||
| Literal bcl = operation.dataType().isRational() | ||
| ? new Literal(bcLiteral.source(), ((Number) bcLiteral.value()).doubleValue(), DataTypes.DOUBLE) |
There was a problem hiding this comment.
Changing this to use new Literal instead of Literal.of resolves #108388
craigtaverner
pushed a commit
to craigtaverner/elasticsearch
that referenced
this pull request
Jun 11, 2024
…9256) This pulls the SimplifyComparisonArithmetics optimization into ESQL proper, from core, and in doing so resolves two of the issues we uncovered with that optimization. Rather than moving this into a sub-class of OptimzierRules, I've opted to create a new package optimizer.rules, and put this as a top level class there. I have another PR open that migrates a bunch of other rules into OptimizerRules, and that's in general an area of the code that's being touched a lot lately. Having top level classes in a package, rather than sub-classes in a single class file, will create fewer conflicts while working on things that are actually unrelated in this type of situation. Although this is a bugfix, I did not mark it for backporting to 8.14. To my knowledge, no users have reported the associated bugs (we found them through migrating tests), and this fix depends on tests and refactorings that were not backported to 8.14. It would be possible to write an 8.14 version of this, but IMHO it's easier to do as a fresh ticket than as a backport and conflict resolution process. If we think that's important, I'm happy to do so, but at the moment I think fixing it for 8.15 is fine. Note that this is a re-application of the changes in elastic#108200 after we did other refactoring, which that was closed to enable. Resolves elastic#108388 Resolves elastic#108743
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pulls the SimplifyComparisonArithmetics optimization into ESQL proper, from core, and in doing so resolves two of the issues we uncovered with that optimization.
Rather than moving this into a sub-class of
OptimzierRules, I've opted to create a new packageoptimizer.rules, and put this as a top level class there. I have another PR open that migrates a bunch of other rules intoOptimizerRules, and that's in general an area of the code that's being touched a lot lately. Having top level classes in a package, rather than sub-classes in a single class file, will create fewer conflicts while working on things that are actually unrelated in this type of situation.Although this is a bugfix, I did not mark it for backporting to 8.14. To my knowledge, no users have reported the associated bugs (we found them through migrating tests), and this fix depends on tests and refactorings that were not backported to 8.14. It would be possible to write an 8.14 version of this, but IMHO it's easier to do as a fresh ticket than as a backport and conflict resolution process. If we think that's important, I'm happy to do so, but at the moment I think fixing it for 8.15 is fine.
Note that this is a re-application of the changes in #108200 after we did other refactoring, which that was closed to enable.
Resolves #108388
Resolves #108743