-
Notifications
You must be signed in to change notification settings - Fork 5.9k
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: split avg to count and sum for TableReader cop task #11926
Conversation
Codecov Report
@@ Coverage Diff @@
## master #11926 +/- ##
===========================================
Coverage 81.4033% 81.4033%
===========================================
Files 444 444
Lines 95560 95560
===========================================
Hits 77789 77789
Misses 12291 12291
Partials 5480 5480 |
/run-all-tests |
/run-integration-common-test |
1 similar comment
/run-integration-common-test |
@lzmhhh123 Does it affect the execution logic on TiKV Coprocessor? |
I'm checking this situation. |
/run-all-tests |
@@ -864,7 +864,7 @@ func (s *testPlanSuite) TestDAGPlanBuilderAgg(c *C) { | |||
// Test agg + table. | |||
{ | |||
sql: "select sum(a), avg(b + c) from t group by d", | |||
best: "TableReader(Table(t)->HashAgg)->HashAgg", | |||
best: "TableReader(Table(t))->Projection->HashAgg", |
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 this one changed?
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.
I felt confused too. So I'm investigating the reason now.
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.
I guess it should be caused by the fact that the number of AggFuncs
increases, so the cost of Aggregation is changed, and planner decides not to push this Agg down to coprocessor.
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.
According to #11926 (comment), seems we should modify the cost model to decrease the impact of number of aggregate functions to make this aggregation can be pushed to tikv?
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.
We can temporarily not to modify the cost model. That's another task of cost model improvement with the consideration of aggregation type.
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.
OK, How about filing an issue about this improvement?
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.
Okay.
It passed the integration-common-test at least. |
Yeah, does it mean that the execution instruction in TiKV is not changed? I'm afraid that this pr would impact the end-to-end performance of a SQL. |
Only a little. Because TiKV executes |
@@ -864,7 +864,7 @@ func (s *testPlanSuite) TestDAGPlanBuilderAgg(c *C) { | |||
// Test agg + table. | |||
{ | |||
sql: "select sum(a), avg(b + c) from t group by d", | |||
best: "TableReader(Table(t)->HashAgg)->HashAgg", | |||
best: "TableReader(Table(t))->Projection->HashAgg", |
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.
I guess it should be caused by the fact that the number of AggFuncs
increases, so the cost of Aggregation is changed, and planner decides not to push this Agg down to coprocessor.
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
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
/run-all-tests |
What problem does this PR solve?
Because the calculation of
avg
in the coprocessor is split assum
andcount
, and it also returns two columns. We can splitavg
in the planner. Now it's only effective for cop agg inTableReader
.A sub PR for support the coprocessor in tiflash.
What is changed and how it works?
Check List
Tests
Side effects
Related changes