Comment 0 for bug 1218321

The AHI partitioning code looks up the latch corresponding to a specific index through a helper (inline) function btr_search_get_latch(). Which calculates the offset into the array of latches as index->id modulo the number of AHI partitions. So it may end up calculating the same number many times per row, even though it is a constant for each particular index.

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-> % btr_search_index_num
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->btr_search_latch, etc.)

The same applies to hash tables protected by the corresponding latches.