[MDEV-6138] show sysvar's help in I_S tables Created: 2014-04-19 Updated: 2015-08-07 Resolved: 2014-10-11 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | OTHER |
| Fix Version/s: | 10.1.1 |
| Type: | Task | Priority: | Major |
| Reporter: | Sergei Golubchik | Assignee: | Sergei Golubchik |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||
| Description |
|
Every sysvar has an associated help text, but it's only accessible as mysqld --help which is kind of a waste. It would be helpful to show it as a third column in INFORMATION_SCHEMA.GLOBAL_VARIABLES and INFORMATION_SCHEMA.SESSION_VARIABLES. For backward compatibility we'll hide this column if @@old_mode=NO_SYSVAR_HELP. Alternatively, we could introduce a new table, say, INFORMATION_SCHEMA.SYSTEM_VARIABLES with all (global and session) variables, without their current values, but with the help, type, valid value range, etc. |
| Comments |
| Comment by Sergei Golubchik [ 2014-05-28 ] | |||||||||||||||||
|
if we extend existing I_S tables, then we can at the same time extend I_S.PLUGIN and I_S.COLLATION to show usage counters (that now only feedback plugin can show). In this case the better name for the old mode would be something like OLD_I_S_TABLES | |||||||||||||||||
| Comment by Michael Widenius [ 2014-08-06 ] | |||||||||||||||||
|
When doing this, we should also show the following:
| |||||||||||||||||
| Comment by Simon J Mudd [ 2014-08-06 ] | |||||||||||||||||
|
Also missing if the global value is static or not.
Perhaps, adding a time of last_update would be useful. I've seen already with P_S that having the stats is great but if you don't know how long they have been configured that way it might be an issue. So perhaps an extra column of the form: last_change TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP (or "boot time"...) might be useful. | |||||||||||||||||
| Comment by Sergei Golubchik [ 2014-09-01 ] | |||||||||||||||||
|
Yes, I'll have the information about static/dynamic. But, probably, not the timestamp — this would have a rather high relative overhead (like 3x – 100x storage overhead, depending on the implementation). | |||||||||||||||||
| Comment by Sergei Golubchik [ 2014-09-03 ] | |||||||||||||||||
|
at the end, I decided to keep old tables and create a new one instead:
|