-
Couldn't load subscription status.
- Fork 25.6k
ESQL: Fix count optimization with pushable union types #127225
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
Changes from 4 commits
7e46eae
c90cacf
3cc50a8
50c8a2a
becc26c
e8251f6
a7e7faa
a08b148
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: 127225 | ||
| summary: Fix count optimization with pushable union types | ||
| area: ES|QL | ||
| type: bug | ||
| issues: | ||
| - 127200 |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -66,12 +66,12 @@ public LogicalPlan apply(LogicalPlan plan, LocalLogicalOptimizerContext localLog | |
|
|
||
| private LogicalPlan missingToNull(LogicalPlan plan, Predicate<FieldAttribute> shouldBeRetained) { | ||
| if (plan instanceof EsRelation relation) { | ||
| // Remove missing fields from the EsRelation because this is not where we will obtain them from; replace them by an Eval right | ||
| // after, instead. This allows us to safely re-use the attribute ids of the corresponding FieldAttributes. | ||
| // For any missing field, place an Eval right after the EsRelation to assign null values to that attribute (using the same name | ||
| // id!), thus avoiding that InsertFieldExtrations inserts a field extraction later. | ||
|
Comment on lines
+69
to
+70
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. 👍 |
||
| // This means that an EsRelation[field1, field2, field3] where field1 and field 3 are missing will be replaced by | ||
| // Project[field1, field2, field3] <- keeps the ordering intact | ||
| // \_Eval[field1 = null, field3 = null] | ||
| // \_EsRelation[field2] | ||
| // \_EsRelation[field1, field2, field3] | ||
|
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. If the field is missing, would it be in the EsRelation at all? 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. Yes! Because we're in the local optimizer, the field does exist overall, and thus is put into the EsRelation after the field caps call on the coordinator. But on the local node it's missing! (Or in the search stats that this optimization run uses, to be more precise) This optimizer rule applies exclusively to such fields. |
||
| List<Attribute> relationOutput = relation.output(); | ||
| Map<DataType, Alias> nullLiterals = Maps.newLinkedHashMapWithExpectedSize(DataType.types().size()); | ||
| List<NamedExpression> newProjections = new ArrayList<>(relationOutput.size()); | ||
|
|
||
| Original file line number | Diff line number | Diff line change | ||
|---|---|---|---|---|
|
|
@@ -94,9 +94,9 @@ private Tuple<List<Attribute>, List<EsStatsQueryExec.Stat>> pushableStats( | |||
| // check if regular field | ||||
| else { | ||||
| if (target instanceof FieldAttribute fa) { | ||||
| var fName = fa.name(); | ||||
| var fName = fa.fieldName(); | ||||
|
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. Wow! Is this the fix? I imagine this could have impacts in many places, so could this fix other bugs we've not noticed? 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. Yep, this is the fix. Simple oversight to use the correct field name - in the past, the field attribute name and the field name were the same, but union types had to break with this pattern. I do not see other situations that this may fix, too, because the specific stats-pushdown optimization only triggers in a narrow slice of queries, anyway. 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. What I'm wondering is if we could make this mistake again and if we could prevent it. Line 58 in 9e0a5af
|
||||
| if (context.searchStats().isSingleValue(fName)) { | ||||
| fieldName = fa.name(); | ||||
| fieldName = fName; | ||||
| query = QueryBuilders.existsQuery(fieldName); | ||||
| } | ||||
| } | ||||
|
|
||||
Uh oh!
There was an error while loading. Please reload this page.