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.
Loading
Please register or sign in to comment