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
Infoschema cache is introduced by #24285, which mainly used for stale read and history read. It let executor can get the corresponding history schema. But even if we have the cache, every request still needs to go to TiKV to obtain the schema version to confirm the corresponding schema. which leads one TiKV to have many KV_Get, This may let one TiKV who has the meta region's leader consume too much CPU and become a bottleneck. And intuitively, the request is unbalanced:
Because the schema version is guaranteed to increase monotonicity in the entire cluster, it could be optimized to reduce the extra request by check the schema version is not changed between the older request and the up-to-date schema version. That's means we need to maintain each schema version's latest ts and oldest ts. if the ts hit in [oldest_ts, latest ts], then we can directly got the schema version.
The text was updated successfully, but these errors were encountered:
Background
Infoschema cache is introduced by #24285, which mainly used for stale read and history read. It let executor can get the corresponding history schema. But even if we have the cache, every request still needs to go to TiKV to obtain the schema version to confirm the corresponding schema. which leads one TiKV to have many
KV_Get
, This may let one TiKV who has the meta region's leader consume too much CPU and become a bottleneck. And intuitively, the request is unbalanced:Implementation
The details are relative to this part:
tidb/domain/domain.go
Lines 101 to 109 in 5c95062
Because the schema version is guaranteed to increase monotonicity in the entire cluster, it could be optimized to reduce the extra request by check the schema version is not changed between the older request and the up-to-date schema version. That's means we need to maintain each schema version's latest ts and oldest ts. if the ts hit in [oldest_ts, latest ts], then we can directly got the schema version.
The text was updated successfully, but these errors were encountered: