TiKV configuration: better description for pin-l0-filter-and-index-blocks

[yiwu-arbug]

First-time contributors' checklist

• I've signed Contributor License Agreement that's required for repo owners to accept my contribution.

What is changed, added or deleted? (Required)

The description for "pin" l0 index and filter block needs to be more descriptive.

Which TiDB version(s) do your changes apply to? (Required)

• master (the latest development version)
• v5.1 (TiDB 5.1 versions)
• v5.0 (TiDB 5.0 versions)
• v4.0 (TiDB 4.0 versions)
• v3.1 (TiDB 3.1 versions)
• v3.0 (TiDB 3.0 versions)
• v2.1 (TiDB 2.1 versions)

What is the related PR or file link(s)?

• This PR is translated from:
• Other reference link(s):

Do your changes match any of the following descriptions?

• Delete files
• Change aliases
• Need modification after applied to another branch
• Might cause conflicts after applied to another branch

[yiwu-arbug]

cc @tabokie

[ti-chi-bot]

[REVIEW NOTIFICATION]

This pull request has been approved by:

• TomShawn
• tabokie

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.

[yiwu-arbug]

Do we want to update for previous versions (all the way back to v3.0) ? @TomShawn

[TomShawn]

Do we want to update for previous versions (all the way back to v3.0) ? @TomShawn

Now we are adopting a new doc content strategy based on @alex-quan-001 's proposal on documentation.

According to Alex: Once the code is frozen and released as a production version, we should not modify the released code, which is exactly how we should handle user documentation. Once the documentation of a product version is delivered, we should not modify the released documentation, no matter it is about typos, incorrect or inaccurate descriptions. These modifications should be made only on the master branch, the latest development branch, and delivered as document enhancements for the upcoming release versions.

In the light of this proposal, as already announced in an R&D weekly meeting, document enhancements and content fixes will not be cherry-picked to release branches. Only the version-specific content affecting only the current release version (e.g. 5.0.3, 4.0.13, and 5.1.0) are permitted for cherry-pick.

[yiwu-arbug]

Do we want to update for previous versions (all the way back to v3.0) ? @TomShawn

Now we are adopting a new doc content strategy based on @alex-quan-001 's proposal on documentation.

According to Alex: Once the code is frozen and released as a production version, we should not modify the released code, which is exactly how we should handle user documentation. Once the documentation of a product version is delivered, we should not modify the released documentation, no matter it is about typos, incorrect or inaccurate descriptions. These modifications should be made only on the master branch, the latest development branch, and delivered as document enhancements for the upcoming release versions.

In the light of this proposal, as already announced in an R&D weekly meeting, document enhancements and content fixes will not be cherry-picked to release branches. Only the version-specific content affecting only the current release version (e.g. 5.0.3, 4.0.13, and 5.1.0) are permitted for cherry-pick.

Got it

[TomShawn]

/merge

[ti-chi-bot]

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

Commit hash: 0cc702b