[MDEV-7716] Spiral patch 018_mariadb-10.0.15.hash_tuning.diff Created: 2015-03-11  Updated: 2017-01-17  Resolved: 2017-01-17

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - Spider
Fix Version/s: 10.2.4

Type: Task Priority: Major
Reporter: Sergey Vojtovich Assignee: Michael Widenius
Resolution: Fixed Votes: 0
Labels: None

Attachments: File 018_mariadb-10.0.15.hash_tuning.diff    
Epic Link: Spiral patches

 Comments   
Comment by Sergey Vojtovich [ 2015-03-13 ]

MariaDB already offers solutions for similar problems: LF_HASH and hash_function() method.

Comment by Michael Widenius [ 2016-12-06 ]

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.

Comment by Sergey Vojtovich [ 2016-12-13 ]

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

Comment by Sergey Vojtovich [ 2016-12-13 ]

monty, I leave it up to you to decide. I believe hash_function() can be used to solve hash value recalculation.

Comment by Michael Widenius [ 2016-12-20 ]

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
Comment by Michael Widenius [ 2017-01-17 ]

Pushed into 10.2. Will merge to 10.2-spider shortly

Generated at Thu Feb 08 07:21:44 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.