Percona Server with XtraDB

Suboptimal AHI partitioning code to access AHI latches and hash tables

Reported by Alexey Kopytov on 2013-08-29
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona Server
Status tracked in 5.6
5.1
Undecided
Unassigned
5.5
Low
Alexey Kopytov
5.6
Low
Alexey Kopytov

Bug Description

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->id % 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.

Alexey Kopytov (akopytov) wrote :

Does not technically apply to 5.6, but will be soon once AHI partitioning is ported there.

tags: added: ahi-partitions
description: updated
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers