Details

    • Type: Task
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Fix Version/s: 10.1.1
    • Component/s: OTHER
    • Labels:
      None

      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.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

              Hide
              serg Sergei Golubchik added a comment -

              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

              Show
              serg Sergei Golubchik added a comment - 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
              Hide
              monty Michael Widenius added a comment -

              When doing this, we should also show the following:

              • Default value
              • How the value was set. One of
              • Default value, Set-by-config-file, Set-by-user, auto-configured (ie, tunned by the server depending on other values)
              Show
              monty Michael Widenius added a comment - When doing this, we should also show the following: Default value How the value was set. One of Default value, Set-by-config-file, Set-by-user, auto-configured (ie, tunned by the server depending on other values)
              Hide
              simon.mudd Simon J Mudd added a comment -

              Also missing if the global value is static or not.

              • some variables are set on startup (so static)
              • others can be changed at any time (so dynamic)
              • others can be changed only when replication is stopped (slave_parallel_workers in MySQL 5.6. There may be something similar in MariaDB). Indicating variables which can only be changed (or their behaviour is picked up) "at certain points in time" would also be useful.

              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.

              Show
              simon.mudd Simon J Mudd added a comment - Also missing if the global value is static or not. some variables are set on startup (so static) others can be changed at any time (so dynamic) others can be changed only when replication is stopped (slave_parallel_workers in MySQL 5.6. There may be something similar in MariaDB). Indicating variables which can only be changed (or their behaviour is picked up) "at certain points in time" would also be useful. 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.
              Hide
              serg Sergei Golubchik added a comment -

              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).

              Show
              serg Sergei Golubchik added a comment - 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).
              Hide
              serg Sergei Golubchik added a comment -

              at the end, I decided to keep old tables and create a new one instead:

              MariaDB [test]> select * from information_schema.system_variables where variable_name='completion_type'\g
              *************************** 1. row ***************************
                      VARIABLE_NAME: COMPLETION_TYPE
                      SESSION_VALUE: CHAIN
                       GLOBAL_VALUE: NO_CHAIN
                GLOBAL_VALUE_ORIGIN: COMPILE-TIME
                      DEFAULT_VALUE: NO_CHAIN
                     VARIABLE_SCOPE: SESSION
                      VARIABLE_TYPE: ENUM
                   VARIABLE_COMMENT: The transaction completion type
                  NUMERIC_MIN_VALUE: NULL
                  NUMERIC_MAX_VALUE: NULL
                 NUMERIC_BLOCK_SIZE: NULL
                    ENUM_VALUE_LIST: NO_CHAIN,CHAIN,RELEASE
                          READ_ONLY: NO
              COMMAND_LINE_ARGUMENT: REQUIRED
              1 row in set (0.00 sec)
              
              Show
              serg Sergei Golubchik added a comment - at the end, I decided to keep old tables and create a new one instead: MariaDB [test]> select * from information_schema.system_variables where variable_name='completion_type'\g *************************** 1. row *************************** VARIABLE_NAME: COMPLETION_TYPE SESSION_VALUE: CHAIN GLOBAL_VALUE: NO_CHAIN GLOBAL_VALUE_ORIGIN: COMPILE-TIME DEFAULT_VALUE: NO_CHAIN VARIABLE_SCOPE: SESSION VARIABLE_TYPE: ENUM VARIABLE_COMMENT: The transaction completion type NUMERIC_MIN_VALUE: NULL NUMERIC_MAX_VALUE: NULL NUMERIC_BLOCK_SIZE: NULL ENUM_VALUE_LIST: NO_CHAIN,CHAIN,RELEASE READ_ONLY: NO COMMAND_LINE_ARGUMENT: REQUIRED 1 row in set (0.00 sec)

                People

                • Assignee:
                  serg Sergei Golubchik
                  Reporter:
                  serg Sergei Golubchik
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  4 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:

                    Time Tracking

                    Estimated:
                    Original Estimate - 1 day Original Estimate - 1 day
                    1d
                    Remaining:
                    Remaining Estimate - 0 minutes
                    0m
                    Logged:
                    Time Spent - 1 week
                    1w