box: introduce offset_slot cache in key_part
tuple_field_by_part looks up the tuple_field corresponding to the given key part in tuple_format in order to quickly retrieve the offset of indexed data from the tuple field map. For regular indexes this operation is blazing fast, however of JSON indexes it is not as we have to parse the path to data and then do multiple lookups in a JSON tree. Since tuple_field_by_part is used by comparators, we should strive to make this routine as fast as possible for all kinds of indexes. This patch introduces an optimization that is supposed to make tuple_field_by_part for JSON indexes as fast as it is for regular indexes in most cases. We do that by caching the offset slot right in key_part. There's a catch here however - we create a new format whenever an index is dropped or created and we don't reindex old tuples. As a result, there may be several generations of tuples in the same space, all using different formats while there's the only key_def used for comparison. To overcome this problem, we introduce the notion of tuple_format epoch. This is a counter incremented each time a new format is created. We store it in tuple_format and key_def, and we only use the offset slot cached in a key_def if it's epoch coincides with the epoch of the tuple format. If they don't, we look up a tuple_field as before, and then update the cached value provided the epoch of the tuple format. Part of #1012
Showing
- src/box/key_def.c 10 additions, 5 deletionssrc/box/key_def.c
- src/box/key_def.h 14 additions, 0 deletionssrc/box/key_def.h
- src/box/tuple.h 1 addition, 1 deletionsrc/box/tuple.h
- src/box/tuple_format.c 4 additions, 1 deletionsrc/box/tuple_format.c
- src/box/tuple_format.h 35 additions, 6 deletionssrc/box/tuple_format.h
Loading
Please register or sign in to comment