Use tiering on intermediate levels, and levelling on the last level. This makes it easier for delete operations to disappear on the last level.

Total number of key/value pairs that can be present in the write buffer before flushing the write buffer to disk.

NOTE: if the sizes of values vary greatly, this can lead to wonky runs on disk, and therefore unpredictable performance.

Allocate a fixed number of bits per physical entry in each bloom filter.

Allocate as many bits as required per physical entry to get the requested false-positive rate. Do this for each bloom filter.

Use a compact fence pointer index.

Compact indexes are designed to work with keys that are large (for example, 32 bytes long) cryptographic hashes.

When using a compact index, it is vital that the serialiseKey function satisfies the following law:

Minimal size

size (serialiseKey x) >= 8

Use serialiseKeyMinimalSize to test this law.

Use an ordinary fence pointer index

Ordinary indexes do not have any constraints on keys other than that their serialised forms may not be 64 KiB or more in size.

Use the OS page cache to cache any/all key/value data in the table.

Use this policy if the expected access pattern for the table has a good spatial or temporal locality.

Use the OS page cache to cache data in all LSMT levels at or below a given level number. For example, use 1 to cache the first level. (The write buffer is considered to be level 0.)

Use this policy if the expected access pattern for the table has good temporal locality for recently inserted keys.

Do not cache any key/value data in any level (except the write buffer).

Use this policy if expected access pattern for the table has poor spatial or temporal locality, such as uniform random access.

Complete merges immediately when started.

The OneShot option will make the merging algorithm perform big batches of work in one go, so intermittent slow-downs can be expected. For use cases where unresponsiveness is unacceptable, e.g. in real-time systems, use Incremental instead.

Schedule merges for incremental construction, and step the merge when updates are performed on a table.

The Incremental option spreads out merging work over time. More specifically, updates to a table can cause a small batch of merge work to be performed. The scheduling of these batches is designed such that merges are fully completed in time for when new merges are started on the same level.