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
SQL: Fix issue with complex HAVING and GROUP BY ordinal #36594
Conversation
Pinging @elastic/es-search |
When trying to analyze a HAVING condition, we crate a temp Aggregate Plan which wasn't created correctly (missing the expressions from the SELECT clause) and as a result the ordinal (1, 2, etc) in the GROUP BY couldn't be resolved correctly. Also after successfully analyzing the HAVING condition, still the original plan was returned. Fixes: elastic#36059
Maybe add a description of the approach taken and what failed ? |
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.
LGTM.
@@ -152,6 +152,9 @@ protected ExecutionInfo executeWithInfo(TreeType plan) { | |||
batchRuns++; | |||
|
|||
for (Rule<?, TreeType> rule : batch.rules) { | |||
if (log.isTraceEnabled()) { | |||
log.trace("Trying to apply rule {}", rule); |
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.
"About to apply rule" - trying implies that it might not be applied.
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.
Which can be the case... But anyway I prefer the "About to apply rule", thx.
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.
LGTM. Left two comments
@@ -209,7 +209,7 @@ public void testGroupByOrderByScalarOverNonGrouped_WithHaving() { | |||
} | |||
|
|||
public void testGroupByHavingNonGrouped() { | |||
assertEquals("1:48: Cannot filter by non-grouped column [int], expected [text]", | |||
assertEquals("1:48: Cannot filter HAVING on non-aggregate [int]; consider using WHERE instead", |
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.
Why are we losing here the text
proposal? Can we still have it?
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.
Thx for catching it, I had it in mind but forgot to open a relevant issue for that.
Here it is: #36693
@@ -396,6 +390,21 @@ public void testTranslateMathFunction_HavingClause_Painless() { | |||
assertThat(aggFilter.scriptTemplate().params().toString(), endsWith(", {v=10}]")); | |||
} | |||
|
|||
public void testGroupByAndHavingWithFunctionOnTopOfAggregation() { | |||
LogicalPlan p = plan("SELECT keyword, max(int) FROM test GROUP BY 1 HAVING " + "abs(max(int)) > 10"); |
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.
HAVING " + "abs(max(int))
- one String only, no need to split it in half.
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.
yep, was some leftover
When trying to analyse a HAVING condition, we crate a temp Aggregate Plan which wasn't created correctly (missing the expressions from the SELECT clause) and as a result the ordinal (1, 2, etc) in the GROUP BY couldn't be resolved correctly. Also after successfully analysing the HAVING condition, still the original plan was returned. Fixes: #36059
Backported to |
When trying to analyse a HAVING condition, we crate a temp Aggregate Plan which wasn't created correctly (missing the expressions from the SELECT clause) and as a result the ordinal (1, 2, etc) in the GROUP BY couldn't be resolved correctly. Also after successfully analysing the HAVING condition, still the original plan was returned. Fixes: #36059
Backported to |
When trying to analyze a HAVING condition, we crate a temp Aggregate
Plan which wasn't created correctly (missing the expressions from the
SELECT clause) and as a result the ordinal (1, 2, etc) in the GROUP BY
couldn't be resolved correctly.
Also after successfully analyzing the HAVING condition, still the
original plan was returned.
Fixes: #36059