Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-33932

QUERY_RESPONSE_TIME_SESSION_STATS is a non-standard way to imitate global+session scope of QUERY_RESPONSE_TIME_STATS

Details

    • Bug
    • Status: Closed (View Workflow)
    • Critical
    • Resolution: Won't Fix
    • N/A
    • N/A
    • Plugins, Variables
    • None

    Description

      MDEV-33501 adds a new variable QUERY_RESPONSE_TIME_SESSION_STATS.

      If I understand the description correctly, it can be set to ON or OFF for the session, in which case it will work accordingly, regardless of QUERY_RESPONSE_TIME_STATS; or it can be set to GLOBAL in which case QUERY_RESPONSE_TIME_STATS will control whether the stats are collected or not.

      If this is correct, I see no purpose to have the variable. It is a behavior of a standard session+global variable of which we have plenty in the server: if @@session.xxx is set to ON and OFF, it works accordingly, and if it is set to DEFAULT, the value of @@global.xxx is used.

      So, instead of adding a new variable, the scope of QUERY_RESPONSE_TIME_STATS should be extended to make it both session and global.

      If there is a reason why it cannot be done so, please elaborate for the documentation purposes why the new variable is needed, and move the ticket to documentation.

      Attachments

        Issue Links

          Activity

            monty Michael Widenius added a comment - - edited

            There are two benefits of the current solution:

            • It is 100% compatible with Percona server.

            By setting @query_response_session_time_stats=global in a config file, a DBA can turn all the statistics ON or OFF instantly.
            Doing things the 'normal way' (having query_response_time_stats a global and session variable) would only affect the users when they connect the next time.

            By default the variable is global, which means that a DB can enable and disable logging of all queries at any point in time. I think that is probably something that they will like.

            monty Michael Widenius added a comment - - edited There are two benefits of the current solution: It is 100% compatible with Percona server. By setting @query_response_session_time_stats=global in a config file, a DBA can turn all the statistics ON or OFF instantly. Doing things the 'normal way' (having query_response_time_stats a global and session variable) would only affect the users when they connect the next time. By default the variable is global, which means that a DB can enable and disable logging of all queries at any point in time. I think that is probably something that they will like.

            What we could do in the the future is to add a way to change all running user's thd bool variables at once (for some variables like query_response_session_stats).
            If we would have that, we would then not have a need for query_response_session_time_stats.

            monty Michael Widenius added a comment - What we could do in the the future is to add a way to change all running user's thd bool variables at once (for some variables like query_response_session_stats). If we would have that, we would then not have a need for query_response_session_time_stats.
            monty Michael Widenius added a comment - - edited

            Until we have a way to affect all running THD users at once, we are better of with Percona's solution.
            I agree that this needs to be documented properly

            monty Michael Widenius added a comment - - edited Until we have a way to affect all running THD users at once, we are better of with Percona's solution. I agree that this needs to be documented properly

            People

              monty Michael Widenius
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.