tidb: update tidb_index_serial_scan_concurrency docs (#21938)#23265
Open
ti-chi-bot wants to merge 1 commit into
Open
tidb: update tidb_index_serial_scan_concurrency docs (#21938)#23265ti-chi-bot wants to merge 1 commit into
ti-chi-bot wants to merge 1 commit into
Conversation
Signed-off-by: ti-chi-bot <ti-community-prow-bot@tidb.io>
ti-chi-bot
added
do-not-merge/hold
12 tasks
Member
Author
|
@0xPoe This PR has conflicts, I have hold it. |
|
@ti-chi-bot: ## If you want to know how to resolve it, please read the guide in TiDB Dev Guide. DetailsInstructions 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. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
ti-chi-bot
Bot
added
size/L
|
@ti-chi-bot: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions 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 kubernetes-sigs/prow repository. I understand the commands that are listed here. |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Code Review
This pull request updates TiDB documentation regarding ANALYZE tasks, concurrency control variables, and TPC-C performance benchmarking. However, unresolved git conflict markers were accidentally committed to statistics.md and system-variables.md, which must be cleaned up. Additionally, the review feedback highlights several style guide violations, such as passive voice overuse and redundant phrasing, alongside minor formatting inconsistencies in SQL code blocks.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
Comment on lines
+965
to
+1036
| <<<<<<< HEAD | ||
| ======= | ||
| ## Manage `ANALYZE` tasks and concurrency | ||
|
|
||
| This section describes how to terminate background `ANALYZE` tasks and control the `ANALYZE` concurrency. | ||
|
|
||
| ### Terminate background `ANALYZE` tasks | ||
|
|
||
| Since TiDB v6.0, TiDB supports using the `KILL` statement to terminate an `ANALYZE` task running in the background. If you find that an `ANALYZE` task running in the background consumes a lot of resources and affects your application, you can terminate the `ANALYZE` task by taking the following steps: | ||
|
|
||
| 1. Execute the following SQL statement: | ||
|
|
||
| ```sql | ||
| SHOW ANALYZE STATUS | ||
| ``` | ||
|
|
||
| By checking the `instance` column and the `process_id` column in the result, you can get the TiDB instance address and the task `ID` of the background `ANALYZE` task. | ||
|
|
||
| 2. Terminate the `ANALYZE` task that is running in the background. | ||
|
|
||
| <CustomContent platform="tidb"> | ||
|
|
||
| - If [`enable-global-kill`](/tidb-configuration-file.md#enable-global-kill-new-in-v610) is `true` (`true` by default), you can execute the `KILL TIDB ${id};` statement directly, where `${id}` is the `ID` of the background `ANALYZE` task obtained from the previous step. | ||
| - If `enable-global-kill` is `false`, you need to use a client to connect to the TiDB instance that is executing the backend `ANALYZE` task, and then execute the `KILL TIDB ${id};` statement. If you use a client to connect to another TiDB instance, or if there is a proxy between the client and the TiDB cluster, the `KILL` statement cannot terminate the background `ANALYZE` task. | ||
|
|
||
| </CustomContent> | ||
|
|
||
| <CustomContent platform="tidb-cloud"> | ||
|
|
||
| To terminate the `ANALYZE` task, you can execute the `KILL TIDB ${id};` statement, where `${id}` is the `ID` of the background `ANALYZE` task obtained from the previous step. | ||
|
|
||
| </CustomContent> | ||
|
|
||
| For more information on the `KILL` statement, see [`KILL`](/sql-statements/sql-statement-kill.md). | ||
|
|
||
| ### Control `ANALYZE` concurrency | ||
|
|
||
| When you run the `ANALYZE` statement, you can adjust the concurrency using system variables, to control its effect on the system. | ||
|
|
||
| The relationships of the relevant system variables are shown below: | ||
|
|
||
|  | ||
|
|
||
| `tidb_build_stats_concurrency`, `tidb_build_sampling_stats_concurrency`, and `tidb_analyze_partition_concurrency` are in an upstream-downstream relationship, as shown in the preceding diagram. The actual total concurrency is: `tidb_build_stats_concurrency` * (`tidb_build_sampling_stats_concurrency` + `tidb_analyze_partition_concurrency`). When modifying these variables, you need to consider their respective values at the same time. It is recommended to adjust them one by one in the order of `tidb_analyze_partition_concurrency`, `tidb_build_sampling_stats_concurrency`, `tidb_build_stats_concurrency`, and observe the impact on the system. The larger the values of these three variables, the greater the resource overhead on the system. | ||
|
|
||
| #### `tidb_build_stats_concurrency` | ||
|
|
||
| This variable controls the concurrency for building statistics during manual `ANALYZE`, such as the number of table or partition analysis tasks that can be processed simultaneously. The default value is `2`. The default value is `4` for v7.4.0 and earlier versions. | ||
|
|
||
| #### `tidb_build_sampling_stats_concurrency` | ||
|
|
||
| This variable controls the following aspects of `ANALYZE` concurrency: | ||
|
|
||
| - The concurrency for merging samples collected from different Regions. | ||
| - The concurrency for collecting statistics on special indexes (such as indexes on generated virtual columns), for example, the number of indexes that TiDB can concurrently collect statistics for. | ||
|
|
||
| The default value is `2`. | ||
|
|
||
| #### `tidb_analyze_partition_concurrency` | ||
|
|
||
| This variable controls the concurrency for saving `ANALYZE` results (writing TopN and histograms to system tables). The default value is `2`. The default value is `1` for v7.4.0 and earlier versions. | ||
|
|
||
| #### `tidb_analyze_distsql_scan_concurrency` | ||
|
|
||
| This variable controls the following aspects of `ANALYZE` concurrency: | ||
|
|
||
| - The concurrency of scanning TiKV Regions. | ||
| - The concurrency of scanning Regions for special indexes (indexes generated from virtual columns). | ||
|
|
||
| The default value is `4`. | ||
|
|
||
| >>>>>>> 3d8180e56a (tidb: update tidb_index_serial_scan_concurrency docs (#21938)) |
Contributor
There was a problem hiding this comment.
Unresolved git conflict markers were committed to this file. Please remove the conflict markers and keep the up-to-date documentation content.
## Manage `ANALYZE` tasks and concurrency
This section describes how to terminate background `ANALYZE` tasks and control the `ANALYZE` concurrency.
### Terminate background `ANALYZE` tasks
Since TiDB v6.0, TiDB supports using the `KILL` statement to terminate an `ANALYZE` task running in the background. If you find that an `ANALYZE` task running in the background consumes a lot of resources and affects your application, you can terminate the `ANALYZE` task by taking the following steps:
1. Execute the following SQL statement:
```sql
SHOW ANALYZE STATUS
```
By checking the `instance` column and the `process_id` column in the result, you can get the TiDB instance address and the task `ID` of the background `ANALYZE` task.
2. Terminate the `ANALYZE` task that is running in the background.
<CustomContent platform="tidb">
- If [`enable-global-kill`](/tidb-configuration-file.md#enable-global-kill-new-in-v610) is `true` (`true` by default), you can execute the `KILL TIDB ${id};` statement directly, where `${id}` is the `ID` of the background `ANALYZE` task obtained from the previous step.
- If `enable-global-kill` is `false`, you need to use a client to connect to the TiDB instance that is executing the backend `ANALYZE` task, and then execute the `KILL TIDB ${id};` statement. If you use a client to connect to another TiDB instance, or if there is a proxy between the client and the TiDB cluster, the `KILL` statement cannot terminate the background `ANALYZE` task.
</CustomContent>
<CustomContent platform="tidb-cloud">
To terminate the `ANALYZE` task, you can execute the `KILL TIDB ${id};` statement, where `${id}` is the `ID` of the background `ANALYZE` task obtained from the previous step.
</CustomContent>
For more information on the `KILL` statement, see [`KILL`](/sql-statements/sql-statement-kill.md).
### Control `ANALYZE` concurrency
When you run the `ANALYZE` statement, you can adjust the concurrency using system variables, to control its effect on the system.
The relationships of the relevant system variables are shown below:
`tidb_build_stats_concurrency`, `tidb_build_sampling_stats_concurrency`, and `tidb_analyze_partition_concurrency` are in an upstream-downstream relationship, as shown in the preceding diagram. The actual total concurrency is: `tidb_build_stats_concurrency` * (`tidb_build_sampling_stats_concurrency` + `tidb_analyze_partition_concurrency`). When modifying these variables, you need to consider their respective values at the same time. It is recommended to adjust them one by one in the order of `tidb_analyze_partition_concurrency`, `tidb_build_sampling_stats_concurrency`, `tidb_build_stats_concurrency`, and observe the impact on the system. The larger the values of these three variables, the greater the resource overhead on the system.
#### `tidb_build_stats_concurrency`
This variable controls the concurrency for building statistics during manual `ANALYZE`, such as the number of table or partition analysis tasks that can be processed simultaneously. The default value is `2`. The default value is `4` for v7.4.0 and earlier versions.
#### `tidb_build_sampling_stats_concurrency`
This variable controls the following aspects of `ANALYZE` concurrency:
- The concurrency for merging samples collected from different Regions.
- The concurrency for collecting statistics on special indexes (such as indexes on generated virtual columns), for example, the number of indexes that TiDB can concurrently collect statistics for.
The default value is `2`.
#### `tidb_analyze_partition_concurrency`
This variable controls the concurrency for saving `ANALYZE` results (writing TopN and histograms to system tables). The default value is `2`. The default value is `1` for v7.4.0 and earlier versions.
#### `tidb_analyze_distsql_scan_concurrency`
This variable controls the following aspects of `ANALYZE` concurrency:
- The concurrency of scanning TiKV Regions.
- The concurrency of scanning Regions for special indexes (indexes generated from virtual columns).
The default value is `4`.
Comment on lines
+1089
to
+1124
| <<<<<<< HEAD | ||
| ======= | ||
| ### tidb_analyze_column_options <span class="version-mark">New in v8.3.0</span> | ||
|
|
||
| > **Note:** | ||
| > | ||
| > - This variable only works when [`tidb_analyze_version`](#tidb_analyze_version-new-in-v510) is set to `2`. | ||
| > - If you upgrade your TiDB cluster from a version earlier than v8.3.0 to v8.3.0 or later, this variable is set to `ALL` by default to keep the original behavior. | ||
| > - For a newly deployed TiDB cluster from v8.3.0 to v8.5.4, this variable is set to `PREDICATE` by default. | ||
| > - For a newly deployed TiDB cluster from v8.5.5 and v9.0.0 onwards, this variable is set to `ALL` by default. | ||
|
|
||
| - Scope: GLOBAL | ||
| - Persists to cluster: Yes | ||
| - Applies to hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): No | ||
| - Type: Enumeration | ||
| - Default value: `ALL` | ||
| - Value options:`ALL`, `PREDICATE` | ||
| - This variable controls the behavior of the `ANALYZE TABLE` statement. Setting it to `PREDICATE` means only collecting statistics for [predicate columns](/statistics.md#collect-statistics-on-some-columns); setting it to `ALL` means collecting statistics for all columns. In scenarios where OLAP queries are used, it is recommended to set it to `ALL`, otherwise collecting statistics can result in a significant drop in query performance. | ||
|
|
||
| ### tidb_analyze_distsql_scan_concurrency <span class="version-mark">New in v7.6.0</span> | ||
|
|
||
| > **Note:** | ||
| > | ||
| > In versions earlier than v7.6.0, regular `ANALYZE` region scans are controlled by `tidb_distsql_scan_concurrency`, and index statistics scans are controlled by `tidb_index_serial_scan_concurrency`. Therefore, to adjust the concurrency of scanning TiKV Regions for these versions, consider changing the value of `tidb_distsql_scan_concurrency`. | ||
|
|
||
| - Scope: SESSION | GLOBAL | ||
| - Persists to cluster: Yes | ||
| - Applies to hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): No | ||
| - Type: Integer | ||
| - Default value: `4` | ||
| - Range: `[0, 4294967295]`. In versions earlier than v8.2.0, the minimum value is `1`. When you set it to `0`, it adaptively adjusts the concurrency based on the cluster size. | ||
| - This variable controls the following aspects of `ANALYZE` concurrency: | ||
| - The concurrency of scanning TiKV Regions. | ||
| - The concurrency of scanning Regions for special indexes, such as indexes on generated virtual columns. | ||
|
|
||
| >>>>>>> 3d8180e56a (tidb: update tidb_index_serial_scan_concurrency docs (#21938)) |
Contributor
There was a problem hiding this comment.
Unresolved git conflict markers were committed to this file. Please remove the conflict markers and keep the up-to-date documentation content.
### tidb_analyze_column_options <span class="version-mark">New in v8.3.0</span>
> **Note:**
>
> - This variable only works when [`tidb_analyze_version`](#tidb_analyze_version-new-in-v510) is set to `2`.
> - If you upgrade your TiDB cluster from a version earlier than v8.3.0 to v8.3.0 or later, this variable is set to `ALL` by default to keep the original behavior.
> - For a newly deployed TiDB cluster from v8.3.0 to v8.5.4, this variable is set to `PREDICATE` by default.
> - For a newly deployed TiDB cluster from v8.5.5 and v9.0.0 onwards, this variable is set to `ALL` by default.
- Scope: GLOBAL
- Persists to cluster: Yes
- Applies to hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): No
- Type: Enumeration
- Default value: `ALL`
- Value options: `ALL`, `PREDICATE`
- This variable controls the behavior of the `ANALYZE TABLE` statement. Setting it to `PREDICATE` means only collecting statistics for [predicate columns](/statistics.md#collect-statistics-on-some-columns); setting it to `ALL` means collecting statistics for all columns. In scenarios where OLAP queries are used, it is recommended to set it to `ALL`, otherwise collecting statistics can result in a significant drop in query performance.
### tidb_analyze_distsql_scan_concurrency <span class="version-mark">New in v7.6.0</span>
> **Note:**
>
> In versions earlier than v7.6.0, regular `ANALYZE` region scans are controlled by `tidb_distsql_scan_concurrency`, and index statistics scans are controlled by `tidb_index_serial_scan_concurrency`. Therefore, to adjust the concurrency of scanning TiKV Regions for these versions, consider changing the value of `tidb_distsql_scan_concurrency`.
- Scope: SESSION | GLOBAL
- Persists to cluster: Yes
- Applies to hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): No
- Type: Integer
- Default value: `4`
- Range: `[0, 4294967295]`. In versions earlier than v8.2.0, the minimum value is `1`. When you set it to `0`, it adaptively adjusts the concurrency based on the cluster size.
- This variable controls the following aspects of `ANALYZE` concurrency:
- The concurrency of scanning TiKV Regions.
- The concurrency of scanning Regions for special indexes, such as indexes on generated virtual columns.
Comment on lines
+1131
to
+1136
| <<<<<<< HEAD | ||
| - This variable specifies the concurrency of reading and writing statistics for a partitioned table when TiDB analyzes the partitioned table. | ||
| ======= | ||
| - Range: `[1, 128]`. Before v8.4.0, the value range is `[1, 18446744073709551615]`. | ||
| - For manual and auto `ANALYZE`, this variable controls the concurrency for saving `ANALYZE` results, including writing TopN and histograms to system tables. | ||
| >>>>>>> 3d8180e56a (tidb: update tidb_index_serial_scan_concurrency docs (#21938)) |
Contributor
There was a problem hiding this comment.
Unresolved git conflict markers were committed to this file. Please remove the conflict markers and keep the up-to-date documentation content.
Suggested change
| <<<<<<< HEAD | |
| - This variable specifies the concurrency of reading and writing statistics for a partitioned table when TiDB analyzes the partitioned table. | |
| ======= | |
| - Range: `[1, 128]`. Before v8.4.0, the value range is `[1, 18446744073709551615]`. | |
| - For manual and auto `ANALYZE`, this variable controls the concurrency for saving `ANALYZE` results, including writing TopN and histograms to system tables. | |
| >>>>>>> 3d8180e56a (tidb: update tidb_index_serial_scan_concurrency docs (#21938)) | |
| - Range: `[1, 128]`. Before v8.4.0, the value range is `[1, 18446744073709551615]`. | |
| - For manual and auto `ANALYZE`, this variable controls the concurrency for saving `ANALYZE` results, including writing TopN and histograms to system tables. |
Comment on lines
+1258
to
+1263
| <<<<<<< HEAD | ||
| - This variable is used to set the concurrency of executing the automatic update of statistics. | ||
| ======= | ||
| - This variable controls the concurrency for building statistics during auto `ANALYZE`, such as the number of table or partition analysis tasks that can be processed simultaneously | ||
| - Starting from v8.5.7 and v9.0.0, the default value of this variable changes from `1` to `2`. If your cluster is upgraded from an earlier version, the value of this variable remains unchanged after the upgrade. | ||
| >>>>>>> 3d8180e56a (tidb: update tidb_index_serial_scan_concurrency docs (#21938)) |
Contributor
There was a problem hiding this comment.
Unresolved git conflict markers were committed to this file. Please remove the conflict markers and keep the up-to-date documentation content.
Suggested change
| <<<<<<< HEAD | |
| - This variable is used to set the concurrency of executing the automatic update of statistics. | |
| ======= | |
| - This variable controls the concurrency for building statistics during auto `ANALYZE`, such as the number of table or partition analysis tasks that can be processed simultaneously | |
| - Starting from v8.5.7 and v9.0.0, the default value of this variable changes from `1` to `2`. If your cluster is upgraded from an earlier version, the value of this variable remains unchanged after the upgrade. | |
| >>>>>>> 3d8180e56a (tidb: update tidb_index_serial_scan_concurrency docs (#21938)) | |
| - This variable controls the concurrency for building statistics during auto `ANALYZE`, such as the number of table or partition analysis tasks that can be processed simultaneously. | |
| - Starting from v8.5.7 and v9.0.0, the default value of this variable changes from `1` to `2`. If your cluster is upgraded from an earlier version, the value of this variable remains unchanged after the upgrade. |
| * Ensure the order of results through indexes | ||
|
|
||
| You can use indexes to filter or sort data. Firstly, get row IDs according to the index order. Then, return the row content according to the return order of row IDs. In this way, the returned results are ordered according to the index column. It has been mentioned earlier that the model of scanning index and getting row is parallel + pipeline. If the row is returned according to the index order, a high concurrency between two queries does not reduce latency. Thus, the concurrency is low by default, but it can be modified through the [`tidb_index_serial_scan_concurrency`](/system-variables.md#tidb_index_serial_scan_concurrency) variable. | ||
| You can use indexes to filter or sort data. TiDB first gets row IDs according to the index order, and then returns the row content according to the order of those row IDs. In this way, the returned results are ordered according to the index column. It has been mentioned earlier that the model of scanning index and getting row is parallel + pipeline. If the row is returned according to the index order, a high concurrency between two queries does not reduce latency. Thus, the concurrency is low by default, but you can increase it by adjusting [`tidb_executor_concurrency`](/system-variables.md#tidb_executor_concurrency-new-in-v50). |
Contributor
There was a problem hiding this comment.
The phrase 'It has been mentioned earlier' uses passive voice, which is discouraged by the style guide. Rephrasing it to 'As mentioned earlier' improves readability and conciseness. Additionally, 'scanning index and getting row' can be improved to 'scanning indexes and retrieving rows' for better grammar.
Suggested change
| You can use indexes to filter or sort data. TiDB first gets row IDs according to the index order, and then returns the row content according to the order of those row IDs. In this way, the returned results are ordered according to the index column. It has been mentioned earlier that the model of scanning index and getting row is parallel + pipeline. If the row is returned according to the index order, a high concurrency between two queries does not reduce latency. Thus, the concurrency is low by default, but you can increase it by adjusting [`tidb_executor_concurrency`](/system-variables.md#tidb_executor_concurrency-new-in-v50). | |
| You can use indexes to filter or sort data. TiDB first gets row IDs according to the index order, and then returns the row content according to the order of those row IDs. In this way, the returned results are ordered according to the index column. As mentioned earlier, the model of scanning indexes and retrieving rows is parallel and pipelined. If TiDB returns rows according to the index order, high concurrency between two queries does not reduce latency. Thus, the concurrency is low by default, but you can increase it by adjusting [`tidb_executor_concurrency`](/system-variables.md#tidb_executor_concurrency-new-in-v50). |
References
- Avoid passive voice overuse (e.g., 'It has been mentioned earlier' -> 'As mentioned earlier'). (link)
| @@ -0,0 +1,123 @@ | |||
| --- | |||
| title: TiDB Cloud TPC-C Performance Test Report for TiDB v8.5.0 | |||
| summary: Introduce the TPC-C performance test results for a TiDB Cloud Dedicated cluster with the TiDB version of v8.5.0. | |||
Contributor
There was a problem hiding this comment.
The phrasing 'with the TiDB version of v8.5.0' is redundant. Using 'with TiDB v8.5.0' is more concise and natural. Also, 'Introduce' in the summary should be 'Introduces' to use the correct present tense.
Suggested change
| summary: Introduce the TPC-C performance test results for a TiDB Cloud Dedicated cluster with the TiDB version of v8.5.0. | |
| summary: Introduces the TPC-C performance test results for a TiDB Cloud Dedicated cluster with TiDB v8.5.0. |
References
- Avoid unnecessary words and repetition. Prefer present tense. (link)
|
|
||
| # TiDB Cloud TPC-C Performance Test Report for TiDB v8.5.0 | ||
|
|
||
| This document provides the TPC-C performance test steps and results for a TiDB Cloud Dedicated cluster with the TiDB version of v8.5.0. This report can also be used as a reference for the performance of TiDB Self-Managed v8.5.0 clusters. |
Contributor
There was a problem hiding this comment.
The phrasing 'with the TiDB version of v8.5.0' is redundant. Using 'with TiDB v8.5.0' is more concise and natural.
Suggested change
| This document provides the TPC-C performance test steps and results for a TiDB Cloud Dedicated cluster with the TiDB version of v8.5.0. This report can also be used as a reference for the performance of TiDB Self-Managed v8.5.0 clusters. | |
| This document provides the TPC-C performance test steps and results for a TiDB Cloud Dedicated cluster with TiDB v8.5.0. This report can also be used as a reference for the performance of TiDB Self-Managed v8.5.0 clusters. |
References
- Avoid unnecessary words and repetition. (link)
Comment on lines
+98
to
+100
| SET tidb_build_stats_concurrency=16; | ||
| SET tidb_build_sampling_stats_concurrency = 16; | ||
| SET tidb_analyze_distsql_scan_concurrency=16; |
Contributor
There was a problem hiding this comment.
The spacing around the assignment operator = is inconsistent in this SQL block. Removing the spaces around = in tidb_build_sampling_stats_concurrency makes it consistent with the other lines.
Suggested change
| SET tidb_build_stats_concurrency=16; | |
| SET tidb_build_sampling_stats_concurrency = 16; | |
| SET tidb_analyze_distsql_scan_concurrency=16; | |
| SET tidb_build_stats_concurrency=16; | |
| SET tidb_build_sampling_stats_concurrency=16; | |
| SET tidb_analyze_distsql_scan_concurrency=16; |
Comment on lines
98
to
+100
| SET tidb_build_stats_concurrency=16; | ||
| SET tidb_distsql_scan_concurrency=16; | ||
| SET tidb_index_serial_scan_concurrency=16; | ||
| SET tidb_build_sampling_stats_concurrency = 16; | ||
| SET tidb_analyze_distsql_scan_concurrency=16; |
Contributor
There was a problem hiding this comment.
The spacing around the assignment operator = is inconsistent in this SQL block. Removing the spaces around = in tidb_build_sampling_stats_concurrency makes it consistent with the other lines.
Suggested change
| SET tidb_build_stats_concurrency=16; | |
| SET tidb_distsql_scan_concurrency=16; | |
| SET tidb_index_serial_scan_concurrency=16; | |
| SET tidb_build_sampling_stats_concurrency = 16; | |
| SET tidb_analyze_distsql_scan_concurrency=16; | |
| SET tidb_build_stats_concurrency=16; | |
| SET tidb_build_sampling_stats_concurrency=16; | |
| SET tidb_analyze_distsql_scan_concurrency=16; |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is an automated cherry-pick of #21938
First-time contributors' checklist
What is changed, added or deleted? (Required)
See: pingcap/tidb#64023
Which TiDB version(s) do your changes apply to? (Required)
Tips for choosing the affected version(s):
By default, CHOOSE MASTER ONLY so your changes will be applied to the next TiDB major or minor releases. If your PR involves a product feature behavior change or a compatibility change, CHOOSE THE AFFECTED RELEASE BRANCH(ES) AND MASTER.
For details, see tips for choosing the affected versions.
What is the related PR or file link(s)?
Do your changes match any of the following descriptions?