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

Add support for SI suffixes in SET statement for configuring size-related variables

Details

    • New Feature
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • None
    • Variables
    • None

    Description

      There are several size-related system variables that can be changed dynamically. e.g.:

      • innodb_log_file_size
      • innodb_buffer_pool_size
      • max_heap_table_size
      • tmp_table_size
      • tmp_disk_table_size
      • binlog_cache_size
      • binlog_file_cache_size
      • binlog_stmt_cache_size
      • etc.

      In configuration files, users are able to set these variables using SI prefixes. e.g.:

      [mariadb]
      innodb_log_file_size=2G

      It would be great if users could do the same thing with SET:

      SET GLOBAL innodb_log_file_size='2G';

      Currently, users would have to do this instead:

      SET GLOBAL innodb_log_file_size=(2 * 1024 * 1024 * 1024);

      Can we implement SI prefixes for SET?

      Attachments

        Issue Links

          Activity

            The International System of Units (Système international) defines metric prefixes of the unit of measurement. The unit of measurement is customarily attached as a suffix, i.e., 123 km.

            A unit of byte (customarily, an octet of binary digits) is not defined in SI, and the prefixes that were suggested are not actually metric (powers of one thousand) but binary (powers of 2¹⁰ = 1,024).

            If we did not already support prefixes in the configuration file parser, we might want to define Ki, Mi, Gi, Ti as powers of 1024, and k,M,G,T as powers of 1000. (Yes, the lower-case k in SI is the prefix for kilo (one thousand), and the upper-case K is for Kelvin, the absolute temperature.)

            I think that to remain compatible with the configuration file parser and the case-insensitive nature of SQL, we had better use case-insensitive interpretation, and use the case-insensitive suffixes K,M,G,T defined as powers of 1,024. That is,

            SET GLOBAL innodb_io_capacity=1K;
            

            would set the number to 1024. Note: in the above example, the parameter does not refer to bytes, but to innodb_page_size×(1+innodb_doublewrite).

            Should we also allow the following?

            CREATE TABLE t (a INT) ENGINE=InnoDB ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=4K;
            

            History: InnoDB hijacked the KEY_BLOCK_SIZE attribute for the fixed compressed page size. The values 1,2,4,8,16 are allowed. We did not use 1024,2048,4096,8192,16384 because it was thought that it is inconvenient for users to type such long numbers.

            marko Marko Mäkelä added a comment - The International System of Units (Système international) defines metric prefixes of the unit of measurement. The unit of measurement is customarily attached as a suffix, i.e., 123 km. A unit of byte (customarily, an octet of binary digits) is not defined in SI, and the prefixes that were suggested are not actually metric (powers of one thousand) but binary (powers of 2¹⁰ = 1,024). If we did not already support prefixes in the configuration file parser, we might want to define Ki, Mi, Gi, Ti as powers of 1024 , and k,M,G,T as powers of 1000. (Yes, the lower-case k in SI is the prefix for kilo (one thousand), and the upper-case K is for Kelvin, the absolute temperature.) I think that to remain compatible with the configuration file parser and the case-insensitive nature of SQL, we had better use case-insensitive interpretation, and use the case-insensitive suffixes K,M,G,T defined as powers of 1,024. That is, SET GLOBAL innodb_io_capacity=1K; would set the number to 1024. Note: in the above example, the parameter does not refer to bytes, but to innodb_page_size ×(1+ innodb_doublewrite ). Should we also allow the following? CREATE TABLE t (a INT ) ENGINE=InnoDB ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=4K; History: InnoDB hijacked the KEY_BLOCK_SIZE attribute for the fixed compressed page size. The values 1,2,4,8,16 are allowed. We did not use 1024,2048,4096,8192,16384 because it was thought that it is inconvenient for users to type such long numbers.

            People

              Unassigned Unassigned
              GeoffMontee Geoff Montee (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

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