Skip to content
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

Skip the creation of DistinctLimitNode for global aggregation node #437

Merged
merged 1 commit into from
Mar 12, 2019

Conversation

Praveen2112
Copy link
Member

Currently if there is a global aggregation node with no aggregation functions and if we try to merge with a limit node we end up creating a DistinctLimitNode which fails when executed because there is no grouping key. So we skip the creation of DistinctLimitNode for such aggregation
nodes.

This is will solve this issue (prestodb/presto#11276).

@cla-bot cla-bot bot added the cla-signed label Mar 11, 2019
@Praveen2112
Copy link
Member Author

@martint , @findepi , @kokosing Can you please review this ?

Copy link
Member

@kokosing kokosing left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good % small comments

@@ -40,7 +40,7 @@
*/
private static boolean isDistinct(AggregationNode node)
{
return node.getAggregations().isEmpty() &&
return node.getAggregations().isEmpty() && !node.getGroupingKeys().isEmpty() &&
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please move each condition to separate line

@@ -40,7 +40,7 @@
*/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add tests for queries that were failing previously.

If you are solving prestodb/presto#11276, then please add below query to io.prestosql.tests.AbstractTestAggregations or AbstractTestQueries:

select count(1) from (select sum(field1) from table limit 10) a;

@@ -134,7 +134,7 @@ public PlanNode visitAggregation(AggregationNode node, RewriteContext<LimitConte
LimitContext limit = context.get();

if (limit != null &&
node.getAggregations().isEmpty() &&
node.getAggregations().isEmpty() && !node.getGroupingKeys().isEmpty() &&
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please move each condition to separate line

@Praveen2112
Copy link
Member Author

@kokosing Have resolved the above comments.

Copy link
Member

@martint martint left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a couple of minor changes.

p.limit(
1,
p.aggregation(
(Consumer<PlanBuilder.AggregationBuilder>) aggregationBuilder -> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The type declaration for the lambda is unnecessary. You can also chain the invocations and shorten the variable name to reduce verbosity:

p.aggregation(builder -> builder
        .singleGroupingSet(p.symbol("foo"))
        .source(p.values(p.symbol("foo"))))))

@Test
public void testAggregationWithConstantArgumentsOverScalar()
{
assertQuery("SELECT count(1) FROM (SELECT count(custkey) FROM orders LIMIT 10) a");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Extra space between FROM and orders

@Praveen2112
Copy link
Member Author

@martint I have updated the changes

Copy link
Member

@martint martint left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. I'll merge it after Travis gives the ok.

Currently if there is a global aggregation node with no aggregation
functions and if we try to merge with a limit node we end up creating a
DistinctLimitNode which fails when executed because there is no grouping
key. So we skip the creation of `DistinctLimitNode` for such aggregation
nodes.
@martint martint merged commit 98bad41 into trinodb:master Mar 12, 2019
@martint martint mentioned this pull request Mar 14, 2019
6 tasks
@Praveen2112 Praveen2112 deleted the skip_distinct_limit branch May 18, 2019 06:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

3 participants