Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Not a Bug
-
Affects Version/s: 5.5.33a
-
Fix Version/s: None
-
Component/s: None
-
Labels:None
Description
it looks like code for aria/hash index is rewritten, while the same for memory|myisam /hash is the same not so good.
tests are made for tables of:
engine = memory, table names are ttmp_mem_*
engine = aria, while the tables are actually on memdisk: ttmp_aria_*
engine = myisam, while tables are actually on memdis: ttmp_myisam_*
engine = aria, tables on SSD disk: tmp_aria_*
engine = myisam, tables on SSD disk: tmp_myisam_*
so update of randomly filled table of ~0.5mln rows, which affect those index , takes different times:
ttmp_mem_btree: 0.30 sec
ttmp_mem_hash: 38.28 sec # THAT IS TIME I SUPPOSE TO BE A BUG
ttmp_myisam_hash: 38.30 sec
ttmp_myisam_btree: 1.30 sec
ttmp_aria_hash: 1.22 sec # BECAUSE OF THIS
ttmp_aria_btree: 1.63 sec
tmp_myisam_hash: 38.09 sec
tmp_myisam_btree: 1.14 sec
tmp_aria_hash: 1.37 sec
tmp_aria_btree: 1.40 sec
sql-script to create+update tables in attach
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
This is not a bug.
1. The Aria engine does not have hash indexes. The requested hash index is silently converted to btree.
2. The behavior seen with the Memory table and the hash index is expected, because both the column type and the initial values in the indexed column will cause heavy hash collisions.
Please see the attached files memslow4.sql and memslow4.log (with execution times and inline comments) for an example how different value distribution affects hash index efficiency.
demonstration of hash index behavior
Axel,
Could you please review the provided information and proceed as needed?
Thanks.