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

avoid read kv for each new session's first select @@variable #10388

Closed
lysu opened this issue May 8, 2019 · 0 comments · Fixed by #10463
Closed

avoid read kv for each new session's first select @@variable #10388

lysu opened this issue May 8, 2019 · 0 comments · Fixed by #10463

Comments

@lysu
Copy link
Contributor

lysu commented May 8, 2019

Bug Report

Please answer these questions before submitting your issue. Thanks!

  1. What did you do?
    If possible, provide a recipe for reproducing the error.

when user uses jdbc or spring, it will auto send many select variable statement like:

select @@tx_ready_only;
select @@net_buffer_length;
select @@max_allowed_packet;
select @@character_set_sever
....and so on

those statements will be frequent send, it's better preload their global variable value into TiDB memory.

We have some other variable already use this mechanism, but some other variable is missed(like above)

var builtinGlobalVariable = []string{

  1. What did you see instead?

frequent used variable's select @@variable, should read session variable or load default value from TiDB local cache, instead of load from kv everytime

  1. What version of TiDB are you using (tidb-server -V or run select tidb_version(); on TiDB)?

3.0.1.beta1

@lysu lysu added component/server help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. and removed help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. labels May 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant