We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
目前lock meta在prepare DML/DQL 下占比较高。 其中部分是锁之外的占比,约占Lock meta的一半,这部分可以做一些优化
所有的优化都在 sql/compile/lock_meta.go中 可能可以优化的部分: 1、目前每次execute结束后,会调用reset,清理掉表达式执行器的结果。感觉这个没有必要。因为每次execute都是一样的database和table,可能只要执行过一次。以后每次都用这个结果即可。不用reset和重新执行。
2、现在调用 lockop.LockRows 的时候,是给的table_id,当lock_op在需要的时候,会通过getReleationById来获取rel,这个函数的实现会比较慢。可以修改为每次调用,重新在外层通过名称和txnOperator拿relation,作为参数传递进去。避免使用getRelationById
No response
The text was updated successfully, but these errors were encountered:
huby2358
No branches or pull requests
Why do you want to refactor this code?
Describe the solution you'd like
所有的优化都在 sql/compile/lock_meta.go中
可能可以优化的部分:
1、目前每次execute结束后,会调用reset,清理掉表达式执行器的结果。感觉这个没有必要。因为每次execute都是一样的database和table,可能只要执行过一次。以后每次都用这个结果即可。不用reset和重新执行。
2、现在调用 lockop.LockRows 的时候,是给的table_id,当lock_op在需要的时候,会通过getReleationById来获取rel,这个函数的实现会比较慢。可以修改为每次调用,重新在外层通过名称和txnOperator拿relation,作为参数传递进去。避免使用getRelationById
Describe alternatives you've considered
No response
Additional information
No response
The text was updated successfully, but these errors were encountered: