SQL: Support queries with HAVING over SELECT #46709
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
|
Pinging @elastic/es-search |
Handle queries with implicit GROUP BY where the aggregation is not in the projection/SELECT but inside the filter/HAVING such as: SELECT 1 FROM x HAVING COUNT(*) > 0 The engine now properly identifies the case Fix elastic#37051
matriv
approved these changes
Sep 16, 2019
| @@ -174,10 +174,12 @@ public QueryContainer(Query query, | |||
| */ | |||
| public BitSet columnMask(List<Attribute> columns) { | |||
| BitSet mask = new BitSet(fields.size()); | |||
| for (Attribute column : columns) { | |||
| for (int columnIndex = 0; columnIndex < columns.size(); columnIndex++) { | |||
There was a problem hiding this comment.
Why do you need this? I don't see columnIndex to be used.
| @@ -227,7 +230,7 @@ public int limit() { | |||
|
|
|||
| public boolean isAggsOnly() { | |||
There was a problem hiding this comment.
Should we rename the method since with anyMatch the name seems misleading now?
There was a problem hiding this comment.
The name is a bit misleading but the meaning holds, the method indicates whether the query is an agg-only or scroll-any.
The issue with some expressions is that they can appear in both contexts (column name or literals), hence the anyMatch.
This might be addressed better through FieldExtraction directly.
There was a problem hiding this comment.
Maybe hasAggsOnly is better?
| @@ -140,6 +140,10 @@ protected PhysicalPlan rule(ProjectExec project) { | |||
| ScalarFunction f = (ScalarFunction) pj; | |||
| processors.put(f.toAttribute(), Expressions.pipe(f)); | |||
| } | |||
| // | |||
There was a problem hiding this comment.
Please remove if not needed.
| @@ -1002,6 +1003,42 @@ protected LogicalPlan rule(Project p) { | |||
| } | |||
| } | |||
|
|
|||
| // | |||
| // Detect implicit grouping with filtering and convert them into aggregates. | |||
| // SELECT 1 FROM x WHERE COUNT(*) > 0 | |||
astefan
approved these changes
Sep 16, 2019
matriv
reviewed
Sep 16, 2019
| + "(InternalSqlScriptUtils.add(InternalSqlScriptUtils.docValue(doc,params.v0)," | ||
| + "InternalSqlScriptUtils.intervalYearMonth(params.v1,params.v2)),params.v3)\",\"lang\":\"painless\"," | ||
| + "\"params\":{\"v0\":\"date\",\"v1\":\"P1Y\",\"v2\":\"INTERVAL_YEAR\",\"v3\":\"Z\"}},\"missing_bucket\":true,")); | ||
| } | ||
|
|
||
|
|
||
| public void testHavingWithLiteralImplicitGrouping() { |
costin
added a commit
that referenced
this pull request
Sep 17, 2019
Handle queries with implicit GROUP BY where the aggregation is not in the projection/SELECT but inside the filter/HAVING such as: SELECT 1 FROM x HAVING COUNT(*) > 0 The engine now properly identifies the case and handles it accordingly. Fix #37051 (cherry picked from commit fa53ca0) (cherry picked from commit 683b5fd)
jkakavas
pushed a commit
to jkakavas/elasticsearch
that referenced
this pull request
Sep 25, 2019
Handle queries with implicit GROUP BY where the aggregation is not in the projection/SELECT but inside the filter/HAVING such as: SELECT 1 FROM x HAVING COUNT(*) > 0 The engine now properly identifies the case and handles it accordingly. Fix elastic#37051
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.
Handle queries with implicit GROUP BY where the aggregation is not in
the projection/SELECT but inside the filter/HAVING such as:
SELECT 1 FROM x HAVING COUNT(*) > 0
The engine now properly identifies the case
Fix #37051