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

Add a MAX_MEMORY_USAGE table option to bound a MEMORY table by bytes rather than by rows

    XMLWordPrintable

Details

    Description

      A MEMORY table can be sized two ways, and neither of them bounds the memory one table uses when its rows carry a BLOB.

      max_heap_table_size bounds bytes, but it is a session variable. Every MEMORY table the session opens is measured against the same value, so it cannot express that one table may use a megabyte while another may use a gigabyte.

      MAX_ROWS and MIN_ROWS are per table, but they are expressed in rows.

      Why a row count does not bound memory

      For a column with a declared width, a row count and a memory figure are related: the record reserves the declared width whatever the row stores, so rows times width is the memory. A BLOB has no declared width. The record holds a length and a pointer, and the bytes sit outside it, so the same row count stands for any amount of memory at all.

      CREATE TABLE t1 (b BLOB) ENGINE=MEMORY MAX_ROWS=10;
      CREATE TABLE t2 (b BLOB) ENGINE=MEMORY MAX_ROWS=10;
      INSERT INTO t1 VALUES (REPEAT('x', 10)), (REPEAT('x', 10));
      INSERT INTO t2 VALUES (REPEAT('x', 60000)), (REPEAT('x', 60000));
      

      The two tables carry the same table option and the same number of rows, and the memory they hold differs by four orders of magnitude. Whatever a user writing MAX_ROWS on a MEMORY table wanted to bound, this is not it.

      Proposal

      A table option, MAX_MEMORY_USAGE, given in bytes, bounding what one MEMORY table may allocate.

      CREATE TABLE t (b BLOB) ENGINE=MEMORY MAX_MEMORY_USAGE=1048576;
      

      The engine already keeps a per-table byte ceiling internally, in HP_CREATE_INFO::max_table_size, which today is filled in from max_heap_table_size alone. A table option would give that field a per-table source.

      Points to settle

      How it combines with max_heap_table_size: whether the table option replaces the session value for that table, or whether the lower of the two applies. Taking the lower keeps the session variable working as an administrative ceiling that a table definition cannot raise, which is the safer reading.

      What a table reports once it has one: DATA_LENGTH and MAX_DATA_LENGTH in information_schema.TABLES should be measured against the table's own ceiling rather than the session one.

      Which error a table full at its own ceiling raises. ER_RECORD_FILE_FULL is what a MEMORY table raises today when it exhausts max_heap_table_size, and reusing it keeps one meaning for one condition.

      Whether MAX_ROWS keeps its present meaning alongside it. The two bound different things and can both be honoured, the table filling at whichever it reaches first.

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              arcivanov Arcadiy Ivanov
              Votes:
              0 Vote for this issue
              Watchers:
              2 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.