Skip to content
Snippets Groups Projects
Commit c344dfff authored by Vladimir Davydov's avatar Vladimir Davydov Committed by Konstantin Osipov
Browse files

vinyl: zap range index

Currently, we store all range ids in an .index file after each range
tree modification. On recovery, we open the latest .index file, get the
list of all ranges, and load them. This .index file introduces extra
complexity to the compaction task: as we can get a consistent list of
all range ids only in the tx thread, we must either write .index file
from the tx thread (which we do now), or introduce a special task for
it, which would be scheduled on compaction completion. The former way
degrades performance of the tx thread, while the latter complicates the
code.

Actually, we can do range recovery w/o having to maintain .index files:
as newer ranges always have greater ids, we can just recover ranges
starting from the greatest id and disregarding ranges that are already
spanned by the index tree. For instance, suppose range A was split in
ranges B and C. Then we recover ranges B and C first (they do not
intersect, so everything's fine), then we get to A and see that it is
already spanned (by B and C), so we just throw it away. If on split, B
(or C) was not created for some reason, then A will not be fully spanned
by the index, and we replace B (or C) with A, still getting a consistent
index view.

This patch implements the recovery process as per above and removes the
.index file. Note, to avoid loading stale index data after drop-create,
we have to name range files not only by id, but also by index lsn (just
like the .index files). As before, old range file removal is postponed
until checkpoint.
parent 559102a7
No related branches found
No related tags found
No related merge requests found
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment