Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decrease loading Region info in RegionCache when using select * from table limit 1 #39733

Closed
AricSu opened this issue Dec 7, 2022 · 2 comments
Labels
duplicate Issues or pull requests already exists. type/enhancement The issue or PR belongs to an enhancement.

Comments

@AricSu
Copy link
Contributor

AricSu commented Dec 7, 2022

Enhancement

original problem : https://asktug.com/t/topic/996693

Background :

  1. We can see there was too many loadRegion from trace info and increased the query_time.
    image

  2. Taking a deep look :the calling chain is func Select --> func (c *CopClient) Send --> func buildCopTasks --> SplitKeyRangesByLocations --> LocateKey --> findRegionByKey --> loadRegion , the action how to actually loadRegion dues to ranges, in tableReader operand building, the ranges are table start_key and end_key. So, it causes a lot of loadRegion actions.

Enhancement : we think , in this scenario, it could be tuned in the way of just requesting specific region info.

@AricSu AricSu added the type/enhancement The issue or PR belongs to an enhancement. label Dec 7, 2022
@tiancaiamao
Copy link
Contributor

tiancaiamao commented Dec 9, 2022

This is a known issue, but not easy to fix.

"Build coprocessor request" component has no idea about the "limit 1" executor, it just see 'key ranges', which may be the whole table. For example, some query need to iterate the while table data (thus all its key range) but just return 1 row...

A possible way to fix this might be making the 'SplitKeyRangesByLocations' lazy execution, so the cop task is built, but its region will not be calculated until the actual use.

@tiancaiamao tiancaiamao added the duplicate Issues or pull requests already exists. label Aug 21, 2023
@tiancaiamao
Copy link
Contributor

Duplicated by #14320
Close this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
duplicate Issues or pull requests already exists. type/enhancement The issue or PR belongs to an enhancement.
Projects
None yet
Development

No branches or pull requests

2 participants