-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
Support widening of numeric types in union-types #112610
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,6 @@ | ||
pr: 112610 | ||
summary: Support widening of numeric types in union-types | ||
area: ES|QL | ||
type: bug | ||
issues: | ||
- 111277 |
Large diffs are not rendered by default.
This file was deleted.
This file was deleted.
This file was deleted.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -115,7 +115,6 @@ | |
import static org.elasticsearch.xpack.esql.core.type.DataType.KEYWORD; | ||
import static org.elasticsearch.xpack.esql.core.type.DataType.LONG; | ||
import static org.elasticsearch.xpack.esql.core.type.DataType.TEXT; | ||
import static org.elasticsearch.xpack.esql.core.type.DataType.UNSIGNED_LONG; | ||
import static org.elasticsearch.xpack.esql.core.type.DataType.VERSION; | ||
import static org.elasticsearch.xpack.esql.core.type.DataType.isTemporalAmount; | ||
import static org.elasticsearch.xpack.esql.stats.FeatureMetric.LIMIT; | ||
|
@@ -1223,8 +1222,7 @@ private Expression resolveConvertFunction(AbstractConvertFunction convert, List< | |
HashMap<TypeResolutionKey, Expression> typeResolutions = new HashMap<>(); | ||
Set<DataType> supportedTypes = convert.supportedTypes(); | ||
imf.types().forEach(type -> { | ||
// TODO: Shouldn't we perform widening of small numerical types here? | ||
if (supportedTypes.contains(type)) { | ||
if (supportedTypes.contains(type.widenSmallNumeric())) { | ||
Comment on lines
-1226
to
+1225
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Contrary to the funny |
||
TypeResolutionKey key = new TypeResolutionKey(fa.name(), type); | ||
var concreteConvert = typeSpecificConvert(convert, fa.source(), type, imf); | ||
typeResolutions.put(key, concreteConvert); | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -63,7 +63,7 @@ protected AbstractConvertFunction(StreamInput in) throws IOException { | |
* Build the evaluator given the evaluator a multivalued field. | ||
*/ | ||
protected final ExpressionEvaluator.Factory evaluator(ExpressionEvaluator.Factory fieldEval) { | ||
DataType sourceType = field().dataType(); | ||
DataType sourceType = field().dataType().widenSmallNumeric(); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Uhh, how did that field not end up being widened in the first place? In What fails if we do not widen here? I'd like to figure out if this is really necessary. Also, to avoid confusion in the future, do you think we should add an assert to There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I was surprised this failed too. It fails later in planning, I don't remember the exact stack trace, but the error was that this function was being called with an unsupported type (the narrow type). I understood the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this deserves a follow up, because there begin to be many places were widening is necessary - and we only find out by failed queries/tests :/ I opened #112691. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I investigated, and this exception is thrown down during query execution (ie. after local physical planning) during the setup of the type converting block loader at https://github.com/elastic/elasticsearch/blob/main/x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/planner/EsPhysicalOperationProviders.java#L384. This is well past any analyzing, planning phases, so it is clear that the types are not widened in general, but only in specific cases. A followup investigation makes a lot of sense. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For completeness, this is the stack trace:
|
||
var factory = factories().get(sourceType); | ||
if (factory == null) { | ||
throw EsqlIllegalArgumentException.illegalDataType(sourceType); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is cool!
However, to reduce risk some more (some data types can be quirky and stuff could happen at block loading time, I guess, to types like
float
andbyte
...); how about we add to this/replace this by a parameterized integration test that exercises all widened data types?RestEsqlTestCase is quite nice and, like csv tests, is executed in multiple environments (single/multi node etc.).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tests in
RestEsqlTestCase
also have the benefit that we can more easily test cases with more than 2 different types becoming a union type. E.g.float
,byte
and, I dunno,keyword
being stuffed intoto_string
.