-
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
*: support coprocessor cache for paging protocol #35787
Conversation
[REVIEW NOTIFICATION] This pull request has been approved by:
To complete the pull request process, please ask the reviewers in the list to review by filling The full list of commands accepted by this bot can be found here. Reviewer can indicate their review by submitting an approval review. |
/run-check-issue-triage-complete |
Code Coverage Details: https://codecov.io/github/pingcap/tidb/commit/9f7128a13ae0e4b5ac319a0a3f8acb4807d3235c |
One compatibility issue I found is that in the old setting, While in the paging protocol, for many cases, the segmented page request takes less than 5ms and is thus not cached. |
I think it is transparent to users. So it is only a behavior change for us. Maybe we could use two different timing parameters for stream/paging. |
store/copr/coprocessor.go
Outdated
copy(end, cacheValue.PageEnd) | ||
} | ||
// When paging protocol is used, the response key range is part of the cache data. | ||
resp.pbResp.Range = &coprocessor.KeyRange{ |
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.
Should we set resp.pbResp.Range = nil
when cacheValue.PageStart/PageEnd == nil
?
/merge |
/merge cancel |
/run-check_dev_2 |
/merge |
This pull request has been accepted and is ready to merge. Commit hash: f7f8f88
|
/run-check_dev_2 |
TiDB MergeCI notify🔴 Bad News! New failing [2] after this pr merged.
|
What problem does this PR solve?
Issue Number: close #35786
Problem Summary:
What is changed and how it works?
The paging protocol breaks coprocessor cache (when I enable paging), now I'd like to bring it back.
It works like this:
For coprocessor paging request, the cache key will add an extra 'paging=1' byte.
After receiving the cop paging response, the cache value will store both the Data and the paging Range.
When the cop paging request hit cache, it will recover both Data and Range information.
So after the handleCopTask, it update the paging range to the next one.
In a work, each of the paging request is cached and reused seperately.
Check List
Tests
Side effects
Documentation
Release note
Please refer to Release Notes Language Style Guide to write a quality release note.