Issues with copr_cache in the TableReader Operator

Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: 关于tablereader算子的copr_cache问题

| username: HTAP萌新

[TiDB Usage Environment] Test
[TiDB Version] 5.7
[Encountered Problem] The same SQL executed twice has a significant time difference. After checking the plan, it was found that the time difference is mainly caused by the tablereader operator. One shows copr_cache_hit=1.0, while the other does not. May I ask which level of cache this is? Is it the block cache of RocksDB? Or is it the cache at the TiKV layer? Can this cache be controlled to enable or disable, or can its size be adjusted?

[Reproduction Path] What operations were performed to encounter the problem
[Problem Phenomenon and Impact]

[Attachment]

Please provide the version information of each component, such as cdc/tikv, which can be obtained by executing cdc version/tikv-server --version.

| username: h5n1 | Original post link

The performance of the TiDB cluster is closely related to the hardware configuration and the number of nodes. Generally, increasing the number of nodes can improve the performance of the TiDB cluster. However, it is also necessary to consider the balance between the number of nodes and the hardware configuration to achieve the best performance.

| username: HTAP萌新 | Original post link

Thank you very much!

| username: system | Original post link

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.