|
MySQL 5.7.2 introduced heap memory allocations for every updated row:
if (node->cascade_heap) {
|
mem_heap_empty(node->cascade_heap);
|
} else {
|
node->cascade_heap = mem_heap_create(128);
|
}
|
|
mem_heap_allocator<upd_node_t*> mem_heap_ator(node->cascade_heap);
|
|
cascade_upd_nodes = new
|
(mem_heap_ator.allocate(sizeof(upd_cascade_t)))
|
upd_cascade_t(deque_mem_heap_t(mem_heap_ator));
|
|
new_upd_nodes = new
|
(mem_heap_ator.allocate(sizeof(upd_cascade_t)))
|
upd_cascade_t(deque_mem_heap_t(mem_heap_ator));
|
|
processed_cascades = new
|
(mem_heap_ator.allocate(sizeof(upd_cascade_t)))
|
upd_cascade_t(deque_mem_heap_t(mem_heap_ator));
|
If the mem_heap_create(128) was replaced with a larger parameter, then these allocations could reuse the same memory heap for every updated row. It would still be unnecessary to allocate the memory when there are no FOREIGN KEY ON (UPDATE|DELETE) (SET NULL|CASCADE) constraints, but we would avoid the multiple calls to mem_heap_create_block_func() on every updated row.
|