Skip the creation of DistinctLimitNode for global aggregation node#437
Skip the creation of DistinctLimitNode for global aggregation node#437martint merged 1 commit intotrinodb:masterfrom
Conversation
There was a problem hiding this comment.
Please move each condition to separate line
There was a problem hiding this comment.
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;
There was a problem hiding this comment.
Please move each condition to separate line
01734cf to
020dd0f
Compare
|
@kokosing Have resolved the above comments. |
020dd0f to
c72e056
Compare
martint
left a comment
There was a problem hiding this comment.
Just a couple of minor changes.
There was a problem hiding this comment.
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"))))))There was a problem hiding this comment.
Extra space between FROM and orders
c72e056 to
3955b22
Compare
|
@martint I have updated the changes |
martint
left a comment
There was a problem hiding this comment.
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.
3955b22 to
854e814
Compare
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
DistinctLimitNodewhich fails when executed because there is no grouping key. So we skip the creation ofDistinctLimitNodefor such aggregationnodes.
This is will solve this issue (prestodb/presto#11276).