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

increased footprint of simple MEMORY tables

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 5.5.25
    • 5.5.27
    • None
    • None

    Description

      Starting with MariaDB 5.5.22 (more exactly: somewhere between r3337 and r3349 in the maria-5.5 tree) simple MEMORY tables start to consume more memory.

      Example:

      create table t1 (c1 int, index (c1)) engine memory;
      – load 50 mio random rows
      show table status;

      Calculating bytes per row gives:

      5.5.r3337: 16 (data) + 16 (index) = 32 bytes total
      5.5.r3349: 17 (data) + 25 (index) = 42 bytes total

      Attachments

        Activity

          The size increase for indexes are expected and what you have to pay for a 30 % - > 50% speedup in index handling. The cost is 1 long / per index entry. (ie 4 bytes for 32 bit system and 8 bytes systems)

          The change for data comes that if you don't specify MAX_ROWS, we allocate smaller block size (=room for 1000 rows /block) instead of 'read_buffer_size". The effect is that for small set of rows we save a LOT of memory while for big number of rows there is a slight increase in the memory used as we need to allocate more blocks with a small overhead per block.

          monty Michael Widenius added a comment - The size increase for indexes are expected and what you have to pay for a 30 % - > 50% speedup in index handling. The cost is 1 long / per index entry. (ie 4 bytes for 32 bit system and 8 bytes systems) The change for data comes that if you don't specify MAX_ROWS, we allocate smaller block size (=room for 1000 rows /block) instead of 'read_buffer_size". The effect is that for small set of rows we save a LOT of memory while for big number of rows there is a slight increase in the memory used as we need to allocate more blocks with a small overhead per block.

          I found a 10+ year old bug in HEAP tables that when we allocated memory for a upper nod level, we allocated 1024 bytes in the case when the tree didn't grow. This explains the extra memory allocation for data.
          I have now fixed that. Will be pushed into 5.5 shortly.

          monty Michael Widenius added a comment - I found a 10+ year old bug in HEAP tables that when we allocated memory for a upper nod level, we allocated 1024 bytes in the case when the tree didn't grow. This explains the extra memory allocation for data. I have now fixed that. Will be pushed into 5.5 shortly.

          Pushed into 5.5 tree

          monty Michael Widenius added a comment - Pushed into 5.5 tree

          People

            monty Michael Widenius
            axel Axel Schwenke
            Votes:
            0 Vote for this issue
            Watchers:
            4 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.