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

planner: fix a corner case in column pruning rule #10974

Merged
merged 3 commits into from
Jul 1, 2019

Conversation

bb7133
Copy link
Member

@bb7133 bb7133 commented Jun 28, 2019

What problem does this PR solve?

This PR tries to close #9125

What is changed and how it works?

For a LogicalAggregation, if all of its functions are pruned and it doesn't have group-by items, a dummy aggregate function is added to keep the correctness.

Check List

Tests

  • Unit test
  • Integration test

Side effects

  • Possible performance regression

Related changes

  • Need to cherry-pick to the release branch

@bb7133 bb7133 added sig/planner SIG: Planner type/bugfix This PR fixes a bug. labels Jun 28, 2019
@codecov
Copy link

codecov bot commented Jun 28, 2019

Codecov Report

Merging #10974 into master will not change coverage.
The diff coverage is n/a.

@@             Coverage Diff             @@
##             master     #10974   +/-   ##
===========================================
  Coverage   81.0119%   81.0119%           
===========================================
  Files           418        418           
  Lines         89335      89335           
===========================================
  Hits          72372      72372           
  Misses        11731      11731           
  Partials       5232       5232

return err
}
la.AggFuncs = []*aggregation.AggFuncDesc{one}
la.schema.Columns = []*expression.Column{{TblName: model.NewCIStr("dummy_cnt"), RetType: types.NewFieldType(mysql.TypeLonglong)}}
Copy link
Contributor

Choose a reason for hiding this comment

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

Fill ColName and UniqueID as well?

Copy link
Member Author

Choose a reason for hiding this comment

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

Done, thanks

if len(la.GroupByItems) == 0 && len(la.AggFuncs) == 0 {
// If all the aggregate functions are pruned and there is no group-by item, we should add
// an aggregate function to keep the correctness.
one, err := aggregation.NewAggFuncDesc(la.ctx, ast.AggFuncCount, []expression.Expression{expression.One}, false)
Copy link
Contributor

Choose a reason for hiding this comment

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

I prefer using first_row(1) here.

Copy link
Member Author

Choose a reason for hiding this comment

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

You're right... first_row is better

@@ -117,6 +119,17 @@ func (la *LogicalAggregation) PruneColumns(parentUsedCols []*expression.Column)
for _, aggrFunc := range la.AggFuncs {
selfUsedCols = expression.ExtractColumnsFromExpressions(selfUsedCols, aggrFunc.Args, nil)
}
if len(la.GroupByItems) == 0 && len(la.AggFuncs) == 0 {
Copy link
Contributor

Choose a reason for hiding this comment

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

If len(la.GroupByItems) > 0 && len(la.AggFuncs) == 0, we'd better add this dummy aggregation function as well. Though the result is correct now, we are depending on the specific implementation of executor, if executor is changed in the future, we may have problem for this case then.

Copy link
Member Author

@bb7133 bb7133 Jun 30, 2019

Choose a reason for hiding this comment

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

Thanks for the explanation

@bb7133
Copy link
Member Author

bb7133 commented Jun 30, 2019

addressed, thank you @eurekaka

Copy link
Contributor

@eurekaka eurekaka left a comment

Choose a reason for hiding this comment

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

LGTM

@eurekaka eurekaka added the status/LGT1 Indicates that a PR has LGTM 1. label Jul 1, 2019
Copy link
Member

@zz-jason zz-jason left a comment

Choose a reason for hiding this comment

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

LGTM

@zz-jason zz-jason added status/LGT2 Indicates that a PR has LGTM 2. and removed status/LGT1 Indicates that a PR has LGTM 1. labels Jul 1, 2019
@zz-jason
Copy link
Member

zz-jason commented Jul 1, 2019

/run-all-tests

@zz-jason zz-jason merged commit 3847ec8 into pingcap:master Jul 1, 2019
@zz-jason
Copy link
Member

zz-jason commented Jul 1, 2019

needs to be cherry-picked to release-2.1 and release-3.0

@bb7133
Copy link
Member Author

bb7133 commented Jul 1, 2019

needs to be cherry-picked to release-2.1 and release-3.0

OKay

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
sig/planner SIG: Planner status/LGT2 Indicates that a PR has LGTM 2. type/bugfix This PR fixes a bug.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

tidb sql count bug
3 participants