Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
5.5.25
-
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
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.
| Field | Original Value | New Value |
|---|---|---|
| Assignee | Michael Widenius [ monty ] |
| Fix Version/s | 5.5.27 [ 11100 ] |
| Resolution | Fixed [ 1 ] | |
| Status | Open [ 1 ] | Closed [ 6 ] |
| Workflow | defaullt [ 13704 ] | MariaDB v2 [ 44073 ] |
| Workflow | MariaDB v2 [ 44073 ] | MariaDB v3 [ 64232 ] |
| Workflow | MariaDB v3 [ 64232 ] | MariaDB v4 [ 144912 ] |
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.