Sergey Vojtovich added a comment - 2015-03-13 12:05 MariaDB already offers solutions for similar problems: LF_HASH and hash_function() method.

Michael Widenius added a comment - 2016-12-06 09:44 Yes, we have LF_HASH, but the old hash is still used a lot and not having to calculate the hash over and over again will speed up things.

Sergey Vojtovich added a comment - 2016-12-13 13:31 Subject: Re: MDEV-7716 - Spiral patch 018_mariadb-10.0.15.hash_tuning.diff   Hi Sergey,   > What was the main problem that this patch is solving? Was it scalability > improvement by moving hash calculation out of mutex? Or was it generic > performance improvement so that hash value is never calculated twice?   It's for both.   > I'm asking because we should have solutions for both cases. There is > HASH::hash_function(), which may be used to return cached hash value > (e.g. see MDL). There is also lock-free hash that offers even better > scalability (btw it also supports hash_function()). Why didn't these > options work for you?   Does it mean "it's already support by MariaDB, and use lock-free hash for scalability" right? If it is right, I'll try to change Spider code for using lock-free hash, and this patch doesn't need to merge.   Thanks, Kentoku

Sergey Vojtovich added a comment - 2016-12-13 13:41 monty , I leave it up to you to decide. I believe hash_function() can be used to solve hash value recalculation.

Michael Widenius added a comment - 2016-12-20 18:27 - edited New implementation with full test case done (the test case also found issues in the original code be Kentoku, so it was good to have it done): Improved mysys/hash.cc by caching hash_nr. This is done without using any additional memory Removed usage of my_hash_search() with uninitialized HASH. Not documented or intended usage Extra checking takes time for all HASH usage

Michael Widenius added a comment - 2017-01-17 09:09 Pushed into 10.2. Will merge to 10.2-spider shortly