Suboptimal AHI partitioning code to access AHI latches and hash tables
|Percona Server||Status tracked in 5.6|
The AHI partitioning code looks up the latch corresponding to a specific index through a helper (inline) function btr_search_
Additionally, for some unknown reasons slots in the array of latches are pointers to latches, rather than the actual latches.
So the following steps are performed whenever InnoDB wants to get an adaptive hash index latch:
1. Read index->id
2. calculate index->id % btr_search_
3. read the base address of the latches array
4. read the latch pointer corresponding to the base address and the offset calculated on step #2.
By making the latch an attribute of the index struct (which it really is), the above can become:
1. Read index->search_latch
Which is not a big optimization in itself, but again that code is sometimes executed on critical code paths many times per each row, and that change also results in a bit cleaner code in a few places (e.g. we don't have to store the latch pointer in a control block of a buffer pool frame, and then do dirty reads and verify if block->index is in sync with block->
The same applies to hash tables protected by the corresponding latches.
- Laurynas Biveinis: Approve on 2013-09-06
- Diff: 1935 lines (+448/-373) 22 files modified (has conflicts)