Document the MemTX's new secondary key build approach
@maryiaLichko is already working on this.
Since Sep 18, 2025.
- Dominant language
- CSS
- Stars
- 15
- Forks
- 49
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 3
Description
Since: 3.5
Now it's possible to sort secondary keys using a new O(n) sorting
algorithm using an additional data written into the snapshot. The
feature can be enabled with a new memtx_use_sort_data option in
box.cfg or memtx.use_sort_data in the instance config.
With the option set to true, additional data is saved into a
separated .sortdata file on snapshot creation and the data is
used on recovery. The default value is false: the behavior has
to be turned on by the user if required.
The option is changeable in runtime. So one can, for example, enable
it on recovery to use the new SK sorting approach, but disable it
before creating a new snapshot, so only .snap file will be created
and the O(n) SK sort will not be available for the snapshot.
The performance impact of the option depends on the persistent
storage read/write speed and the amount of tuples and secondary
keys in spaces (the more the better the new approach is). Also,
the approach only utilizes a single CPU core.
As a downside, it creates an additional footprint overhead on
recovery time (up to ~45 bytes per tuple) and overhead during
the snapshot creation (since we have to write the sort data to
the persistent storage).
Requested by @mkostoevr in https://github.com/tarantool/tarantool/commit/f7db783f37d3f5182bb00f7b23e8be111ace0b8d.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.