Bug #29349 dropping MEMORY table very slow
Submitted: 26 Jun 2007 1:01 Modified: 27 Jun 2007 15:33
Reporter: Jacek Becla Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: Memory storage engine Severity:S3 (Non-critical)
Version:5.0.27 OS:Any
Assigned to: CPU Architecture:Any
Tags: delete, Drop, memory storage, slow, truncate
Triage: Triaged: D3 (Medium)

[26 Jun 2007 1:01] Jacek Becla
Description:
Deleting a large MEMORY table is very slow. For example we observed it took 11 minutes to drop memory table with 6 million rows. Increasing read_buffer_size which seems to be tide to granularity of memory allocation helps (down from 11 min to under 20 sec). Per discussion with Brian Aker, there is no pool allocator for memory tables and free() is called for each row. It should be fixed. 

I tried it with 5.0.27

How to repeat:
Create MEMORY table: few million rows, row size ~2K, then try dropping it.
[26 Jun 2007 10:46] Shane Bester
regarding the read_buffer_size allocations, I had already filed bug #29178 to discuss that
[2 Feb 2014 14:12] Shane Bester
this is still a problem. I had around 18GB of memory tables and it took long enough to drop.

mysql> drop database test;create database test;use test;
Query OK, 126 rows affected (2 min 54.31 sec)