3589 Dmitry Lenev 2011-10-23
Fix for bug #13116518 - "OPEN_TABLES() SHOULD NOT ALLOCATE AND FREE
NEW_FRM_MEM WITHOUT NEEDING TO".
During the process of opening tables for a statement, we allocated
memory which was used only during view loading even in cases when the
statement didn't use any views. Such an unnecessary allocation (and
corresponding freeing) might have caused significant performance
overhead in some workloads. For example, it caused up to 15% slowdown
in a simple stored routine calculating Fibonacci's numbers.
This memory was pre-allocated as part of "new_frm_mem" MEM_ROOT
initialization at the beginning of open_tables().
This patch addresses this issue by turning off memory pre-allocation
during initialization for this MEM_ROOT. Now, memory on this root
will be allocated only at the point when the first .FRM for a view is
The patch doesn't contain a test case since it is hard to test the
performance improvements or the absence of memory allocation in our
3588 Ashish Agarwal 2011-10-22 [merge]
bug#11758979 - 51252: ARCHIVE TABLES STILL FAIL UNDER STRESS
TESTS: CRASH, CORRUPTION, 4G MEMOR
Issue: Valgrind errors due to checksum and optimize
query against archive tables with null columns.
Table record buffer was not initialized.
Solution: Initialize the record buffer.
=== modified file 'sql/sql_base.cc'
--- a/sql/sql_base.cc 2011-08-24 12:22:11 +0000
+++ b/sql/sql_base.cc 2011-10-23 05:37:35 +0000
@@ -4810,10 +4810,11 @@ bool open_tables(THD *thd, TABLE_LIST **
- temporary mem_root for new .frm parsing.
- TODO: variables for size
+ Initialize temporary MEM_ROOT for new .FRM parsing. Do not allocate
+ anything yet, to avoid penalty for statements which don't use views
+ and thus new .FRM format.
- init_sql_alloc(&new_frm_mem, 8024, 8024);
+ init_sql_alloc(&new_frm_mem, 8024, 0);
No bundle (reason: useless for push emails).
|• bzr push into mysql-5.5 branch (Dmitry.Lenev:3588 to 3589) Bug#13116518||Dmitry Lenev||24 Oct|