You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
TiDB indexes data with global index, which lead to a problem that when data grows, some the required data may be sharded into many regions. One of those problem is when reading with indexlookup executor, the table scan may be divided into many coprocessor tasks.
As the figure shows, the continuous index range may point to many discontinuous handle ranges in indexlookup executor. The default tidb_distsql_scan_concurrency is 15, with a big number of handle read tasks, the concurrency is not sufficient and the latency increases. I wrote a script to reproduce this issue.
Solution
Note we can know the entries in handle ranges because TiDB guarantees the consistency of index and data, which means we already know the size of coprocessor tasks when reading handles, and we can adjust the concurrency by increasing the extra concurrency for small tasks. Small tasks won't block other queries on TiKV side because they are extremely fast(mostly less than 1ms on TiKV side).
The text was updated successfully, but these errors were encountered:
Enhancement
Background
TiDB indexes data with global index, which lead to a problem that when data grows, some the required data may be sharded into many regions. One of those problem is when reading with indexlookup executor, the table scan may be divided into many coprocessor tasks.
As the figure shows, the continuous index range may point to many discontinuous handle ranges in indexlookup executor. The default
tidb_distsql_scan_concurrency
is 15, with a big number of handle read tasks, the concurrency is not sufficient and the latency increases. I wrote a script to reproduce this issue.Solution
Note we can know the entries in handle ranges because TiDB guarantees the consistency of index and data, which means we already know the size of coprocessor tasks when reading handles, and we can adjust the concurrency by increasing the extra concurrency for small tasks. Small tasks won't block other queries on TiKV side because they are extremely fast(mostly less than 1ms on TiKV side).
The text was updated successfully, but these errors were encountered: