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

*: restrict index range mem usage #37754

Merged
merged 28 commits into from Sep 21, 2022
Merged

Conversation

xuyifangreeneyes
Copy link
Contributor

What problem does this PR solve?

Issue Number: ref #37176

Problem Summary:

What is changed and how it works?

Restrict index range mem usage. Part 3 of #37160.

Check List

Tests

  • Unit test
  • Integration test
  • Manual test (add detailed scripts or steps below)
  • No code

Side effects

  • Performance regression: Consumes more CPU
  • Performance regression: Consumes more Memory
  • Breaking backward compatibility

Documentation

  • Affects user behaviors
  • Contains syntax changes
  • Contains variable changes
  • Contains experimental features
  • Changes MySQL compatibility

Release note

Please refer to Release Notes Language Style Guide to write a quality release note.

None

@ti-chi-bot
Copy link
Member

ti-chi-bot commented Sep 10, 2022

[REVIEW NOTIFICATION]

This pull request has been approved by:

  • Yisaer
  • time-and-fate

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 release-note-none size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. labels Sep 10, 2022
Copy link
Contributor

@Yisaer Yisaer left a comment

Choose a reason for hiding this comment

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

rest lgtm

Copy link
Contributor

@Yisaer Yisaer left a comment

Choose a reason for hiding this comment

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

rest lgtm

Comment on lines 216 to 230
// Estimate whether rangeMaxSize will be exceeded first before appending points to ranges.
if rangeMaxSize > 0 && len(origin) > 0 && len(rangePoints) > 0 {
startPoint, err := convertPoint(sctx, rangePoints[0], ft)
if err != nil {
return nil, false, errors.Trace(err)
}
endPoint, err := convertPoint(sctx, rangePoints[1], ft)
if err != nil {
return nil, false, errors.Trace(err)
}
ran := appendPoint2Range(origin[0], startPoint, endPoint, ft)
if ran.MemUsage()*int64(len(origin))*int64(len(rangePoints))/2 > rangeMaxSize {
return origin, true, nil
}
}
Copy link
Contributor

Choose a reason for hiding this comment

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

What if the first rangePoint has large/tiny data which caused the estimate difference too big?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Changed the way to estimate mem usage of ranges. Now we iterating origin and rangePoints to sum up mem usage of datums.

@ti-chi-bot ti-chi-bot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Sep 16, 2022
@ti-chi-bot ti-chi-bot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Sep 16, 2022
}
colEqConstant := isColEqConstant(filter, path.IdxCols[i])
if i == eqOrInCount && colEqConstant {
// If there is a col-eq-constant condition for path.IdxCols[eqOrInCount], it means that range fallback happens
Copy link
Member

Choose a reason for hiding this comment

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

I can't understand this. Why does a col = constant condition mean fallback happened?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If range fallback doesn't happen, DetachCondAndBuildRangeForIndex must put col = constant to path.AccessConds rather than path.TableFilters.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

i == eqOrInCount && colEqConstant IF is to prevent the following case:

create table t (a int, b int, c int, index idx_a_b(a, b));
set @@tidb_opt_range_max_size=1000;
explain format='brief' select /*+ use_index(t, idx_a_b) */ * from t where a in (1, 3, 5) and b = 2;

DetachCondAndBuildRangeForIndex puts a in (1, 3, 5) into path.AccessConds and puts b = 2 into path.TableFilters. Without i == eqOrInCount && colEqConstant IF, SplitCorColAccessCondFromFilters adds b = 2 back into path.AccessConds but doesn't rebuild ranges, which leads to wrong results.

Copy link
Member

Choose a reason for hiding this comment

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

Got it.
As you said, I think another reason we need to do this here is that, if the additional AccessConds added here are not caused by correlated columns, then we will not try to build ranges using the additional conditions, which will lead to incomplete range and then wrong results.
I think we can clarify it in the comments.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes. The IF branch ensures that there must be some col-eq-corcol condition in access if len(access) > 0. Actually the first one in access must be some col-eq-corcol condition. I add it to comment in code.

Copy link
Member

@time-and-fate time-and-fate left a comment

Choose a reason for hiding this comment

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

We can add a test case with expressions like (a,b) in ((1,2),(3,4)) and c = 5 to cover more considerDNF code path of detachCNFCondAndBuildRangeForIndex().

}
colEqConstant := isColEqConstant(filter, path.IdxCols[i])
if i == eqOrInCount && colEqConstant {
// If there is a col-eq-constant condition for path.IdxCols[eqOrInCount], it means that range fallback happens
Copy link
Member

Choose a reason for hiding this comment

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

Got it.
As you said, I think another reason we need to do this here is that, if the additional AccessConds added here are not caused by correlated columns, then we will not try to build ranges using the additional conditions, which will lead to incomplete range and then wrong results.
I think we can clarify it in the comments.

}
// Estimate whether rangeMaxSize will be exceeded first before appending ranges to point ranges.
if rangeMaxSize > 0 && estimateMemUsageForAppendRanges2PointRanges(pointRanges, ranges) > rangeMaxSize {
return ranges, true
Copy link
Member

Choose a reason for hiding this comment

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

It seems we should return pointRanges here to be consistent with other places.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good catch! Fixed.

if len1 == 0 || len2 == 0 {
return 0
}
getDatumSize := func(rs Ranges) int64 {
Copy link
Member

Choose a reason for hiding this comment

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

Seems we repeated the "adding up all memory usage of Datums in a Range" logic several times (including the one in the MemUsage()), I think we can unify them maybe some time.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Use getRangesTotalDatumSize and getPointsTotalDatumSize to reuse common logic.

@xuyifangreeneyes
Copy link
Contributor Author

We can add a test case with expressions like (a,b) in ((1,2),(3,4)) and c = 5 to cover more considerDNF code path of detachCNFCondAndBuildRangeForIndex().

I Add some test cases to cover considerDNF code path.

@xuyifangreeneyes
Copy link
Contributor Author

/run-unit-test

@xuyifangreeneyes
Copy link
Contributor Author

/run-unit-test

@xuyifangreeneyes
Copy link
Contributor Author

/run-unit-test

@xuyifangreeneyes
Copy link
Contributor Author

/build

@xuyifangreeneyes
Copy link
Contributor Author

/rebuild

@xuyifangreeneyes
Copy link
Contributor Author

/build

@xuyifangreeneyes
Copy link
Contributor Author

/run-build

@xuyifangreeneyes
Copy link
Contributor Author

/run-build

@xuyifangreeneyes
Copy link
Contributor Author

/run-unit-test

@xuyifangreeneyes
Copy link
Contributor Author

/run-build

1 similar comment
@xuyifangreeneyes
Copy link
Contributor Author

/run-build

@xuyifangreeneyes
Copy link
Contributor Author

/run-mysql-test

@xuyifangreeneyes
Copy link
Contributor Author

/run-build

1 similar comment
@xuyifangreeneyes
Copy link
Contributor Author

/run-build

@xuyifangreeneyes
Copy link
Contributor Author

/run-unit-test

@xuyifangreeneyes
Copy link
Contributor Author

/run-unit-test

@xuyifangreeneyes
Copy link
Contributor Author

/run-unit-test

@xuyifangreeneyes
Copy link
Contributor Author

/run-build

@ti-chi-bot ti-chi-bot merged commit da3dab1 into pingcap:master Sep 21, 2022
@xuyifangreeneyes xuyifangreeneyes deleted the range-mem-3 branch September 21, 2022 16:30
@sre-bot
Copy link
Contributor

sre-bot commented Sep 21, 2022

TiDB MergeCI notify

✅ Well Done! New fixed [1] after this pr merged.

CI Name Result Duration Compare with Parent commit
idc-jenkins-ci-tidb/common-test 🔴 failed 1, success 10, total 11 52 min Existing failure
idc-jenkins-ci-tidb/integration-ddl-test 🔴 failed 2, success 4, total 6 23 min Existing failure
idc-jenkins-ci-tidb/tics-test 🔴 failed 1, success 0, total 1 4 min 12 sec Existing failure
idc-jenkins-ci/integration-cdc-test ✅ all 37 tests passed 26 min Fixed
idc-jenkins-ci-tidb/integration-common-test 🟢 all 17 tests passed 10 min Existing passed
idc-jenkins-ci-tidb/sqllogic-test-1 🟢 all 26 tests passed 5 min 23 sec Existing passed
idc-jenkins-ci-tidb/sqllogic-test-2 🟢 all 28 tests passed 4 min 42 sec Existing passed
idc-jenkins-ci-tidb/mybatis-test 🟢 all 1 tests passed 3 min 4 sec Existing passed
idc-jenkins-ci-tidb/integration-compatibility-test 🟢 all 1 tests passed 2 min 32 sec Existing passed
idc-jenkins-ci-tidb/plugin-test 🟢 build success, plugin test success 4min Existing passed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release-note-none size/XXL Denotes a PR that changes 1000+ 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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants