Reviewing LevelDB: Part XV–MemTables gets compacted too

as mentioned before, every 4 mb or so, we will move the current memtable and switch to a new one, turning the current one into an immutable memtable, which will then be compacted to disk. this post is about that process. the work there is done by the surprisingly name: dbimpl::compactmemtable, which then calls to writelevel0table.

that method build the actual table, using the same approach i already covered. honestly, the code is pretty obvious now that i spent enough time reading this. the only thing of interest is deleteobsoletefiles() method, which looks interesting if only because it is one of the few places leveldb actually does real work with files. mostly, however, parsefilename is interesting:

it give me a good way to look at the actual files being used. this will be important when we will investigate how leveldb handles recovery.

leveldb will consider files obsolete if:

• they are log files and aren't of the current/previous log number.
• if it is a manifest file, keep the current one (or later if there are any).
• if it is a table file, keep it if it is in use. a table file may have been compacted away.
• if it is a lock file, info log or the current db file.

all of this is interesting, but on a minor level. i think that we are nearing the end of the codebase now. the only thing that i really want to go into is the recovery parts, and that would pretty much be it.