Hi, Michael, On Dec 30, Michael Widenius wrote:
On Fri, Dec 27, 2024 at 8:12 PM Sergei Golubchik wrote:
commit b16319bdd0f Author: Michael Widenius <monty@mariadb.org> AuthorDate: Thu Nov 21 12:28:57 2024 +0200 Commit: Michael Widenius <monty@mariadb.org> CommitDate: Fri Dec 27 13:53:37 2024 +0200
diff --git a/storage/heap/hp_block.c b/storage/heap/hp_block.c index 324efc8b4af..44bca363746 100644 --- a/storage/heap/hp_block.c +++ b/storage/heap/hp_block.c @@ -75,9 +75,11 @@ int hp_get_new_block(HP_SHARE *info, HP_BLOCK *block, size_t *alloc_length) Next time we allocate data for X rows. When level 1 is full, we allocate data for HP_PTRS_IN_NOD at level 2 and 1 + X rows at level 0. */ *alloc_length= (sizeof(HP_PTRS) * ((i == block->levels) ? i : i - 1) + (ulonglong)block->records_in_block * block->recbuffer); + /* Alloc in blocks of powers of 2 */ + *alloc_length= MY_MAX(*alloc_length, block->alloc_size);
What will happen to block->alloc_size - *alloc_length bytes? they'll be unused?
Yes. It is better to have that small part unused than have malloc() use it for other purposes, which would cause fragmentation. The algorithm used to calculate row position assumes we have the same amount of rows in each segment. Could be fixed, but better to not do that now.
I've added some stats printing here, they show that your change can increase the memory usage by 30% and more: 13328 -> 16352 (+3024) 22.69 % 12488 -> 16352 (+3864) 30.94 % 12304 -> 16352 (+4048) 32.90 % not the total usage of course, but it can allocate up 30% larger buffers in some cases. Over the course of whole mtr run it loses 1.4M, that is 1.5%. Not much. Ok. Regards, Sergei Chief Architect, MariaDB Server and security@mariadb.org