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/core: change agg cost factor (#25210) #25241

Merged
merged 3 commits into from
Jun 18, 2021

Conversation

ti-srebot
Copy link
Contributor

@ti-srebot ti-srebot commented Jun 8, 2021

cherry-pick #25210 to release-5.0
You can switch your code base to this Pull Request by using git-extras:

# In tidb repo:
git pr https://github.com/pingcap/tidb/pull/25241

After apply modifications, you can push your change to this PR via:

git push git@github.com:ti-srebot/tidb.git pr/25241:release-5.0-a7f3c4d8bd89

What problem does this PR solve?

Problem Summary:

Right now the cost factor of only-group-by (always transformed from select distinct ....) statements is 1.0, leading to not pushing down agg in pseodu stats senerios. However, the cost factor is not reasonable to set 1.0 while the first-row's cost factor is only 0.1. This results in some unexpected behaviours, such as:

mysql> explain select a, b from t1 group by a;
+---------------------------+----------+-----------+---------------+-----------------------------------------------------------------------------------------------+
| id                        | estRows  | task      | access object | operator info                                                                                 |
+---------------------------+----------+-----------+---------------+-----------------------------------------------------------------------------------------------+
| HashAgg_9                 | 8000.00  | root      |               | group by:test.t1.a, funcs:firstrow(test.t1.a)->test.t1.a, funcs:firstrow(Column#5)->test.t1.b |
| └─TableReader_10          | 8000.00  | root      |               | data:HashAgg_5                                                                                |
|   └─HashAgg_5             | 8000.00  | cop[tikv] |               | group by:test.t1.a, funcs:firstrow(test.t1.b)->Column#5                                       |
|     └─TableFullScan_8     | 10000.00 | cop[tikv] | table:t1      | keep order:false, stats:pseudo                                                                |
+---------------------------+----------+-----------+---------------+-----------------------------------------------------------------------------------------------+
4 rows in set (0.00 sec)

mysql> explain select a from t1 group by a;
+--------------------------+----------+-----------+---------------+----------------------------------------------------------+
| id                       | estRows  | task      | access object | operator info                                            |
+--------------------------+----------+-----------+---------------+----------------------------------------------------------+
| HashAgg_7                | 8000.00  | root      |               | group by:test.t1.a, funcs:firstrow(test.t1.a)->test.t1.a |
| └─TableReader_12         | 10000.00 | root      |               | data:TableFullScan_11                                    |
|   └─TableFullScan_11     | 10000.00 | cop[tikv] | table:t1      | keep order:false, stats:pseudo                           |
+--------------------------+----------+-----------+---------------+----------------------------------------------------------+
3 rows in set (0.00 sec)

It's hard to say which one is better because of the lack of stats info. But at least keeping same behaviours will not cause perils. In some MPP senarios, such as every complicated sql, the plans closer to the root (TiDB) might miss the stats info and choose 1-phase aggregation. Considering 2-phase agg is better than 1-phase in most cases, I think this change is beneficial.

However, we still need some experiments and reliable tests to calibrate the cost factors. This work should be done in the near future.

What is changed and how it works?

What's Changed:
change the factor of only-group-by agg from 1.0 to 0.1, which is same as first-row.

Tests

  • Unit test. Over 100 lines of relavent tests are changed. Some tests involed with in-subquery will generate a "distinct" group by. I have checked the test changes and made sure they are safe.

Release note

  • planner/core: change agg cost factor

Signed-off-by: ti-srebot <ti-srebot@pingcap.com>
@ti-srebot ti-srebot requested a review from a team as a code owner June 8, 2021 07:47
@ti-srebot ti-srebot requested review from lzmhhh123 and removed request for a team June 8, 2021 07:47
@ti-srebot
Copy link
Contributor Author

/run-all-tests

@ti-srebot ti-srebot added size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. type/5.0-cherry-pick labels Jun 8, 2021
@ti-srebot ti-srebot requested review from qw4990 and winoros June 8, 2021 07:47
@ti-srebot ti-srebot added this to the v5.0.2 milestone Jun 8, 2021
@ti-srebot
Copy link
Contributor Author

@hanfei1991 you're already a collaborator in bot's repo.

@ti-chi-bot ti-chi-bot added the status/LGT1 Indicates that a PR has LGTM 1. label Jun 16, 2021
@ti-chi-bot
Copy link
Member

[REVIEW NOTIFICATION]

This pull request has been approved by:

  • winoros
  • xiongjiwei

To complete the pull request process, please ask the reviewers in the list to review by filling /cc @reviewer in the comment.
After your PR has acquired the required number of LGTMs, you can assign this pull request to the committer in the list by filling /assign @committer in the comment to help you merge this pull request.

The full list of commands accepted by this bot can be found here.

Reviewer can indicate their review by submitting an approval review.
Reviewer can cancel approval by submitting a request changes review.

@ti-chi-bot ti-chi-bot added status/LGT2 Indicates that a PR has LGTM 2. and removed status/LGT1 Indicates that a PR has LGTM 1. labels Jun 18, 2021
@zhouqiang-cl zhouqiang-cl added backport-5.0.3 cherry-pick-approved Cherry pick PR approved by release team. labels Jun 18, 2021
@hanfei1991
Copy link
Member

/merge

@ti-chi-bot
Copy link
Member

This pull request has been accepted and is ready to merge.

Commit hash: db75bb5

@ti-chi-bot ti-chi-bot added the status/can-merge Indicates a PR has been approved by a committer. label Jun 18, 2021
@ti-chi-bot
Copy link
Member

@ti-srebot: Your PR was out of date, I have automatically updated it for you.

At the same time I will also trigger all tests for you:

/run-all-tests

If the CI test fails, you just re-trigger the test that failed and the bot will merge the PR for you after the CI passes.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the ti-community-infra/tichi repository.

@hanfei1991
Copy link
Member

/run-check_dev

@ti-chi-bot ti-chi-bot merged commit ad3c114 into pingcap:release-5.0 Jun 18, 2021
@hanfei1991 hanfei1991 deleted the release-5.0-a7f3c4d8bd89 branch June 18, 2021 14:10
@zhouqiang-cl zhouqiang-cl modified the milestones: v5.0.2, v5.0.3 Jun 28, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cherry-pick-approved Cherry pick PR approved by release team. size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. status/can-merge Indicates a PR has been approved by a committer. status/LGT2 Indicates that a PR has LGTM 2. type/5.0-cherry-pick
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants