@nxtedition/rocksdb 12.1.4 → 12.1.6

package/deps/rocksdb/rocksdb/include/rocksdb/compaction_job_stats.h

@@ -19,80 +19,82 @@ struct CompactionJobStats {
   void Add(const CompactionJobStats& stats);
 
   // the elapsed time of this compaction in microseconds.
-  uint64_t elapsed_micros;
+  uint64_t elapsed_micros = 0;
 
   // the elapsed CPU time of this compaction in microseconds.
-  uint64_t cpu_micros;
+  uint64_t cpu_micros = 0;
 
   // Used internally indicating whether a subcompaction's
   // `num_input_records` is accurate.
-  bool has_num_input_records;
+  bool has_num_input_records = false;
   // the number of compaction input records.
-  uint64_t num_input_records;
+  uint64_t num_input_records = 0;
   // the number of blobs read from blob files
-  uint64_t num_blobs_read;
+  uint64_t num_blobs_read = 0;
   // the number of compaction input files (table files)
-  size_t num_input_files;
+  size_t num_input_files = 0;
   // the number of compaction input files at the output level (table files)
-  size_t num_input_files_at_output_level;
+  size_t num_input_files_at_output_level = 0;
 
   // the number of compaction output records.
-  uint64_t num_output_records;
+  uint64_t num_output_records = 0;
   // the number of compaction output files (table files)
-  size_t num_output_files;
+  size_t num_output_files = 0;
   // the number of compaction output files (blob files)
-  size_t num_output_files_blob;
+  size_t num_output_files_blob = 0;
 
   // true if the compaction is a full compaction (all live SST files input)
-  bool is_full_compaction;
+  bool is_full_compaction = false;
   // true if the compaction is a manual compaction
-  bool is_manual_compaction;
+  bool is_manual_compaction = false;
+  // true if the compaction ran in a remote worker
+  bool is_remote_compaction = false;
 
   // the total size of table files in the compaction input
-  uint64_t total_input_bytes;
+  uint64_t total_input_bytes = 0;
   // the total size of blobs read from blob files
-  uint64_t total_blob_bytes_read;
+  uint64_t total_blob_bytes_read = 0;
   // the total size of table files in the compaction output
-  uint64_t total_output_bytes;
+  uint64_t total_output_bytes = 0;
   // the total size of blob files in the compaction output
-  uint64_t total_output_bytes_blob;
+  uint64_t total_output_bytes_blob = 0;
 
   // number of records being replaced by newer record associated with same key.
   // this could be a new value or a deletion entry for that key so this field
   // sums up all updated and deleted keys
-  uint64_t num_records_replaced;
+  uint64_t num_records_replaced = 0;
 
   // the sum of the uncompressed input keys in bytes.
-  uint64_t total_input_raw_key_bytes;
+  uint64_t total_input_raw_key_bytes = 0;
   // the sum of the uncompressed input values in bytes.
-  uint64_t total_input_raw_value_bytes;
+  uint64_t total_input_raw_value_bytes = 0;
 
   // the number of deletion entries before compaction. Deletion entries
   // can disappear after compaction because they expired
-  uint64_t num_input_deletion_records;
+  uint64_t num_input_deletion_records = 0;
   // number of deletion records that were found obsolete and discarded
   // because it is not possible to delete any more keys with this entry
   // (i.e. all possible deletions resulting from it have been completed)
-  uint64_t num_expired_deletion_records;
+  uint64_t num_expired_deletion_records = 0;
 
   // number of corrupt keys (ParseInternalKey returned false when applied to
   // the key) encountered and written out.
-  uint64_t num_corrupt_keys;
+  uint64_t num_corrupt_keys = 0;
 
   // Following counters are only populated if
   // options.report_bg_io_stats = true;
 
   // Time spent on file's Append() call.
-  uint64_t file_write_nanos;
+  uint64_t file_write_nanos = 0;
 
   // Time spent on sync file range.
-  uint64_t file_range_sync_nanos;
+  uint64_t file_range_sync_nanos = 0;
 
   // Time spent on file fsync.
-  uint64_t file_fsync_nanos;
+  uint64_t file_fsync_nanos = 0;
 
   // Time spent on preparing file write (fallocate, etc)
-  uint64_t file_prepare_write_nanos;
+  uint64_t file_prepare_write_nanos = 0;
 
   // 0-terminated strings storing the first 8 bytes of the smallest and
   // largest key in the output.
@@ -102,10 +104,10 @@ struct CompactionJobStats {
   std::string largest_output_key_prefix;
 
   // number of single-deletes which do not meet a put
-  uint64_t num_single_del_fallthru;
+  uint64_t num_single_del_fallthru = 0;
 
   // number of single-deletes which meet something other than a put
-  uint64_t num_single_del_mismatch;
+  uint64_t num_single_del_mismatch = 0;
 
   // TODO: Add output_to_penultimate_level output information
 };

package/deps/rocksdb/rocksdb/include/rocksdb/comparator.h

@@ -179,13 +179,18 @@ class Comparator : public Customizable, public CompareInterface {
   size_t timestamp_size_;
 };
 
-// Return a builtin comparator that uses lexicographic byte-wise
-// ordering.  The result remains the property of this module and
-// must not be deleted.
+// Return a builtin comparator that uses lexicographic ordering
+// on unsigned bytes, so the empty string is ordered before everything
+// else and a sufficiently long string of \xFF orders after anything.
+// CanKeysWithDifferentByteContentsBeEqual() == false
+// Returns an immortal pointer that must not be deleted by the caller.
 const Comparator* BytewiseComparator();
 
-// Return a builtin comparator that uses reverse lexicographic byte-wise
-// ordering.
+// Return a builtin comparator that is the reverse ordering of
+// BytewiseComparator(), so the empty string is ordered after everything
+// else and a sufficiently long string of \xFF orders before anything.
+// CanKeysWithDifferentByteContentsBeEqual() == false
+// Returns an immortal pointer that must not be deleted by the caller.
 const Comparator* ReverseBytewiseComparator();
 
 // Returns a builtin comparator that enables user-defined timestamps (formatted

package/deps/rocksdb/rocksdb/include/rocksdb/convenience.h

@@ -56,7 +56,9 @@ struct ConfigOptions {
                      // setting
   };
 
-  // When true, any unused options will be ignored and OK will be returned
+  // When true, any unused options will be ignored and OK will be returned.
+  // For options files that appear to be from the current version or earlier,
+  // unknown options are considered corruption regardless of this setting.
   bool ignore_unknown_options = false;
 
   // When true, any unsupported options will be ignored and OK will be returned

package/deps/rocksdb/rocksdb/include/rocksdb/experimental.h

@@ -61,83 +61,89 @@ Status UpdateManifestForFilesState(
 // EXPERIMENTAL new filtering features
 // ****************************************************************************
 
-// A class for splitting a key into meaningful pieces, or "segments" for
-// filtering purposes. Keys can also be put in "categories" to simplify
-// some configuration and handling. To simplify satisfying some filtering
-// requirements, the segments must encompass a complete key prefix (or the whole
-// key) and segments cannot overlap.
-//
-// Once in production, the behavior associated with a particular Name()
-// cannot change. Introduce a new Name() when introducing new behaviors.
+// KeySegmentsExtractor - A class for splitting a key into meaningful pieces, or
+// "segments" for filtering purposes. We say the first key segment has segment
+// ordinal 0, the second has segment ordinal 1, etc. To simplify satisfying some
+// filtering requirements, the segments must encompass a complete key prefix (or
+// the whole key). There cannot be gaps between segments (though segments are
+// allowed to be essentially unused), and segments cannot overlap.
+//
+// Keys can also be put in "categories" to simplify some configuration and
+// handling. A "legal" key or bound is one that does not return an error (as a
+// special, unused category) from the extractor. It is also allowed for all
+// keys in a category to return an empty sequence of segments.
+//
+// To eliminate a confusing distinction between a segment that is empty vs.
+// "not present" for a particular key, each key is logically assiciated with
+// an infinite sequence of segments, including some infinite tail of 0-length
+// segments. In practice, we only represent a finite sequence that (at least)
+// covers the non-trivial segments.
+//
+// Once in production, the behavior associated with a particular GetId()
+// cannot change. Introduce a new GetId() when introducing new behaviors.
 // See also SstQueryFilterConfigsManager below.
 //
-// OTHER CURRENT LIMITATIONS (maybe relaxed in the future for segments only
-// needing point query or WHERE filtering):
-// * Assumes the (default) byte-wise comparator is used.
-// * Assumes the category contiguousness property: that each category is
-// contiguous in comparator order. In other words, any key between two keys of
-// category c must also be in category c.
-// * Assumes the (weak) segment ordering property (described below) always
-// holds. (For byte-wise comparator, this is implied by the segment prefix
-// property, also described below.)
-// * Not yet compatible with user timestamp feature
-//
-// SEGMENT ORDERING PROPERTY: For maximum use in filters, especially for
-// filtering key range queries, we must have a correspondence between
-// the lexicographic ordering of key segments and the ordering of keys
-// they are extracted from. In other words, if we took the segmented keys
-// and ordered them primarily by (byte-wise) order on segment 0, then
-// on segment 1, etc., then key order of the original keys would not be
-// violated. This is the WEAK form of the property, where multiple keys
-// might generate the same segments, but such keys must be contiguous in
-// key order. (The STRONG form of the property is potentially more useful,
-// but for bytewise comparator, it can be inferred from segments satisfying
-// the weak property by assuming another segment that extends to the end of
-// the key, which would be empty if the segments already extend to the end
-// of the key.)
-//
-// The segment ordering property is hard to think about directly, but for
-// bytewise comparator, it is implied by a simpler property to reason about:
-// the segment prefix property (see below). (NOTE: an example way to satisfy
-// the segment ordering property while breaking the segment prefix property
-// is to have a segment delimited by any byte smaller than a certain value,
-// and not include the delimiter with the segment leading up to the delimiter.
-// For example, the space character is ordered before other printable
-// characters, so breaking "foo bar" into "foo", " ", and "bar" would be
-// legal, but not recommended.)
-//
-// SEGMENT PREFIX PROPERTY: If a key generates segments s0, ..., sn (possibly
-// more beyond sn) and sn does not extend to the end of the key, then all keys
-// starting with bytes s0+...+sn (concatenated) also generate the same segments
-// (possibly more). For example, if a key has segment s0 which is less than the
-// whole key and another key starts with the bytes of s0--or only has the bytes
-// of s0--then the other key must have the same segment s0. In other words, any
-// prefix of segments that might not extend to the end of the key must form an
-// unambiguous prefix code. See
-// https://en.wikipedia.org/wiki/Prefix_code  In other other words, parsing
-// a key into segments cannot use even a single byte of look-ahead. Upon
-// processing each byte, the extractor decides whether to cut a segment that
-// ends with that byte, but not one that ends before that byte. The only
-// exception is that upon reaching the end of the key, the extractor can choose
-// whether to make a segment that ends at the end of the key.
+// This feature hasn't yet been validated with user timestamp.
+//
+// = A SIMPLIFIED MODEL =
+// Let us start with the easiest set of contraints to satisfy with a key
+// segments extractor that generally allows for correct point and range
+// filtering, and add complexity from there. Here we first assume
+// * The column family is using the byte-wise comparator, or reverse byte-wise
+// * A single category is assigned to all keys (by the extractor)
+// * Using simplified criteria for legal segment extraction, the "segment
+//   maximal prefix property"
+//
+// SEGMENT MAXIMAL PREFIX PROPERTY: The segment that a byte is assigned to can
+// only depend on the bytes that come before it, not on the byte itself nor
+// anything later including the full length of the key or bound.
+//
+// Equivalently, two keys or bounds must agree on the segment assignment of
+// position i if the two keys share a common byte-wise prefix up to at least
+// position i - 1 (and i is within bounds of both keys).
+//
+// This specifically excludes "all or nothing" segments where it is only
+// included if it reaches a particular width or delimiter. A segment resembling
+// the FixedPrefixTransform would be illegal (without other assumptions); it
+// must be like CappedPrefixTransform.
+//
+// This basically matches the notion of parsing prefix codes (see
+// https://en.wikipedia.org/wiki/Prefix_code) except we have to include any
+// partial segment (code word) at the end whenever an extension to that key
+// might produce a full segment. An example would be parsing UTF-8 into
+// segments corresponding to encoded code points, where any incomplete code
+// at the end must be part of a trailing segment. Note a three-way
+// correspondence between
+// (a) byte-wise ordering of encoded code points, e.g.
+//     { D0 98 E2 82 AC }
+//     { E2 82 AC D0 98 }
+// (b) lexicographic-then-byte-wise ordering of segments that are each an
+//     encoded code point, e.g.
+//     {{ D0 98 } { E2 82 AC }}
+//     {{ E2 82 AC } { D0 98 }}
+// and (c) lexicographic ordering of the decoded code points, e.g.
+//     { U+0418 U+20AC }
+//     { U+20AC U+0418 }
+// The correspondence between (a) and (b) is a result of the segment maximal
+// prefix property and is critical for correct application of filters to
+// range queries. The correspondence with (c) is a handy attribute of UTF-8
+// (with no over-long encodings) and might be useful to the application.
 //
 // Example types of key segments that can be freely mixed in any order:
-// * Some fixed number of bytes or codewords.
-// * Ends in a delimiter byte or codeword. (Not including the delimiter as
-// part of the segment leading up to it would very likely violate the segment
-// prefix property.)
-// * Length-encoded sequence of bytes or codewords. The length could even
-// come from a preceding segment.
+// * Capped number of bytes or codewords. The number cap for the segment
+// could be the same for all keys or encoded earlier in the key.
+// * Up to *and including* a delimiter byte or codeword.
 // * Any/all remaining bytes to the end of the key, though this implies all
 // subsequent segments will be empty.
-// For each kind of segment, it should be determined before parsing the segment
-// whether an incomplete/short parse will be treated as a segment extending to
-// the end of the key or as an empty segment.
+// As part of the segment maximal prefix property, if the segments do not
+// extend to the end of the key, that must be implied by the bytes that are
+// in segments, NOT because the potential contents of a segment were considered
+// incomplete.
 //
 // For example, keys might consist of
 // * Segment 0: Any sequence of bytes up to and including the first ':'
 // character, or the whole key if no ':' is present.
-// * Segment 1: The next four bytes, all or nothing (in case of short key).
+// * Segment 1: The next four bytes, or less if we reach end of key.
 // * Segment 2: An unsigned byte indicating the number of additional bytes in
 // the segment, and then that many bytes (or less up to the end of the key).
 // * Segment 3: Any/all remaining bytes in the key
@@ -145,22 +151,208 @@ Status UpdateManifestForFilesState(
 // For an example of what can go wrong, consider using '4' as a delimiter
 // but not including it with the segment leading up to it. Suppose we have
 // these keys and corresponding first segments:
-// "123456" -> "123"
-// "124536" -> "12"
-// "125436" -> "125"
+// "123456" -> "123" (in file 1)
+// "124536" -> "12"  (in file 2)
+// "125436" -> "125" (in file 1)
 // Notice how byte-wise comparator ordering of the segments does not follow
 // the ordering of the keys. This means we cannot safely use a filter with
-// a range of segment values for filtering key range queries.
+// a range of segment values for filtering key range queries. For example,
+// we might get a range query for ["123", "125Z") and miss that key "124536"
+// in file 2 is in range because its first segment "12" is out of the range
+// of the first segments on the bounds, "123" and "125". We cannot even safely
+// use this for prefix-like range querying with a Bloom filter on the segments.
+// For a query ["12", "124Z"), segment "12" would likely not match the Bloom
+// filter in file 1 and miss "123456".
 //
-// Also note that it is legal for all keys in a category (or many categories)
-// to return an empty sequence of segments.
+// CATEGORIES: The KeySegmentsExtractor is allowed to place keys in categories
+// so that different parts of the key space can use different filtering
+// strategies. The following property is generally recommended for safe filter
+// applicability
+// * CATEGORY CONTIGUOUSNESS PROPERTY: each category is contiguous in
+//   comparator order. In other words, any key between two keys of category c
+//   must also be in category c.
+// An alternative to categories when distinct kinds of keys are interspersed
+// is to leave some segments empty when they do not apply to that key.
+// Filters are generally set up to handle an empty segment specially so that
+// it doesn't interfere with tracking accurate ranges on non-empty occurrences
+// of the segment.
 //
-// To eliminate a confusing distinction between a segment that is empty vs.
-// "not present" for a particular key, each key is logically assiciated with
-// an infinite sequence of segments, including some infinite tail of 0-length
-// segments. In practice, we only represent a finite sequence that (at least)
-// covers the non-trivial segments.
+// = BEYOND THE SIMPLIFIED MODEL =
+//
+// DETAILED GENERAL REQUIREMENTS (incl OTHER COMPARATORS): The exact
+// requirements on a key segments extractor depend on whether and how we use
+// filters to answer queries that they cannot answer directly. To understand
+// this, we describe
+// (A) the types of filters in terms of data they represent and can directly
+// answer queries about,
+// (B) the types of read queries that we want to use filters for, and
+// (C) the assumptions that need to be satisfied to connect those two.
+//
+// TYPES OF FILTERS: Although not exhaustive, here are some useful categories
+// of filter data:
+// * Equivalence class filtering - Represents or over-approximates a set of
+// equivalence classes on keys. The size of the representation is roughly
+// proportional to the number of equivalence classes added. Bloom and ribbon
+// filters are examples.
+// * Order-based filtering - Represents one or more subranges of a key space or
+// key segment space. A filter query only requires application of the CF
+// comparator. The size of the representation is roughly proportional to the
+// number of subranges and to the key or segment size. For example, we call a
+// simple filter representing a minimum and a maximum value for a segment a
+// min-max filter.
 //
+// TYPES OF READ QUERIES and their DIRECT FILTERS:
+// * Point query - Whether there {definitely isn't, might be} an entry for a
+// particular key in an SST file (or partition, etc.).
+// The DIRECT FILTER for a point query is an equivalence class filter on the
+// whole key.
+// * Range query - Whether there {definitely isn't, might be} any entries
+// within a lower and upper key bound, in an SST file (or partition, etc.).
+//    NOTE: For this disucssion, we ignore the detail of inclusive vs.
+//    exclusive bounds by assuming a generalized notion of "bound" (vs. key)
+//    that conveniently represents spaces between keys. For details, see
+//    https://github.com/facebook/rocksdb/pull/11434
+// The DIRECT FILTER for a range query is an order-based filter on the whole
+// key (non-empty intersection of bounds/keys). Simple minimum and maximum
+// keys for each SST file are automatically provided by metadata and used in
+// the read path for filtering (as well as binary search indexing).
+//    PARTITIONING NOTE: SST metadata partitions do not have recorded minimum
+//    and maximum keys, so require some special handling for range query
+//    filtering. See https://github.com/facebook/rocksdb/pull/12872 etc.
+// * Where clauses - Additional constraints that can be put on range queries.
+// Specifically, a where clause is a tuple <i,j,c,b1,b2> representing that the
+// concatenated sequence of segments from i to j (inclusive) compares between
+// b1 and b2 according to comparator c.
+//    EXAMPLE: To represent that segment of ordinal i is equal to s, that would
+//    be <i,i,bytewise_comparator,before(s),after(s)>.
+//    NOTE: To represent something like segment has a particular prefix, you
+//    would need to split the key into more segments appropriately. There is
+//    little loss of generality because we can combine adjacent segments for
+//    specifying where clauses and implementing filters.
+// The DIRECT FILTER for a where clause is an order-based filter on the same
+// sequence of segments and comparator (non-empty intersection of bounds/keys),
+// or in the special case of an equality clause (see example), an equivalence
+// class filter on the sequence of segments.
+//
+// GENERALIZING FILTERS (INDIRECT):
+// * Point queries can utilize essentially any kind of filter by extracting
+// applicable segments of the query key (if not using whole key) and querying
+// the corresponding equivalence class or trivial range.
+//    NOTE: There is NO requirement e.g. that the comparator used by the filter
+//    match the CF key comparator or similar. The extractor simply needs to be
+//    a pure function that does not return "out of bounds" segments.
+//    FOR EXAMPLE, a min-max filter on the 4th segment of keys can also be
+//    used for filtering point queries (Get/MultiGet) and could be as
+//    effective and much more space efficient than a Bloom filter, depending
+//    on the workload.
+//
+// Beyond point queries, we generally expect the key comparator to be a
+// lexicographic / big endian ordering at a high level (or the reverse of that
+// ordering), while each segment can use an arbitrary comparator.
+//    FOR EXAMPLE, with a custom key comparator and segments extractor,
+//    segment 0 could be a 4-byte unsigned little-endian integer,
+//    segment 1 could be an 8-byte signed big-endian integer. This framework
+//    requires segment 0 to come before segment 1 in the key and to take
+//    precedence in key ordering (i.e. segment 1 order is only consulted when
+//    keys are equal in segment 0).
+//
+// * Equivalence class filters can apply to range queries under conditions
+// resembling legacy prefix filtering (prefix_extractor). An equivalence class
+// filter on segments i through j and category set s is applicable to a range
+// query from lb to ub if
+//   * All segments through j extracted from lb and ub are equal.
+//     NOTE: being in the same filtering equivalence class is insufficient, as
+//     that could be unrelated inputs with a hash collision. Here we are
+//     omitting details that would formally accommodate comparators in which
+//     different bytes can be considered equal.
+//   * The categories of lb and ub are in the category set s.
+//   * COMMON SEGMENT PREFIX PROPERTY (for all x, y, z; params j, s): if
+//     * Keys x and z have equal segments up through ordinal j, and
+//     * Keys x and z are in categories in category set s, and
+//     * Key y is ordered x < y < z according to the CF comparator,
+//   then both
+//     * Key y has equal segments up through ordinal j (compared to x and z)
+//     * Key y is in a category in category set s
+//  (This is implied by the SEGMENT MAXIMAL PREFIX PROPERTY in the simplified
+//  model.)
+//
+// * Order-based filters on segments (rather than whole key) can apply to range
+// queries (with "whole key" bounds). Specifically, an order-based filter on
+// segments i through j and category set s is applicable to a range query from
+// lb to ub if
+//   * All segments through i-1 extracted from lb and ub are equal
+//   * The categories of lb and ub are in the category set s.
+//   * SEGMENT ORDERING PROPERTY for ordinal i through j, segments
+//   comparator c, category set s, for all x, y, and z: if
+//     * Keys x and z have equal segments up through ordinal i-1, and
+//     * Keys x and z are in categories in category set s, and
+//     * Key y is ordered x < y < z according to the CF comparator,
+// then both
+//     * The common segment prefix property is satisifed through ordinal i-1
+//     and with category set s
+//     * x_i..j <= y_i..j <= z_i..j according to segment comparator c, where
+//     x_i..j is the concatenation of segments i through j of key x (etc.).
+//     (This is implied by the SEGMENT MAXIMAL PREFIX PROPERTY in the simplified
+//     model.)
+//
+// INTERESTING EXAMPLES:
+// Consider a segment encoding called BadVarInt1 in which a byte with
+// highest-order bit 1 means "start a new segment". Also consider BadVarInt0
+// which starts a new segment on highest-order bit 0.
+//
+// Configuration: bytewise comp, BadVarInt1 format for segments 0-3 with
+// segment 3 also continuing to the end of the key
+// x = 0x 20 21|82 23|||
+// y = 0x 20 21|82 23 24|85||
+// z = 0x 20 21|82 23|84 25||
+//
+// For i=j=1, this set of keys violate the common segment prefix property and
+// segment ordering property, so can lead to incorrect equivalence class
+// filtering or order-based filtering.
+//
+// Suppose we modify the configuration so that "short" keys (empty in segment
+// 2) are placed in an unfiltered category. In that case, x above doesn't meet
+// the precondition for being limited by segment properties. Consider these
+// keys instead:
+// x = 0x 20 21|82 23 24|85||
+// y = 0x 20 21|82 23 24|85 26|87|
+// z = 0x 20 21|82 23 24|85|86|
+// m = 0x 20 21|82 23 25|85|86|
+// n = 0x 20 21|82 23|84 25||
+//
+// Although segment 1 values might be out of order with key order,
+// re-categorizing the short keys has allowed satisfying the common segment
+// prefix property with j=1 (and with j=0), so we can use equivalence class
+// filters on segment 1, or 0, or 0 to 1. However, violation of the segment
+// ordering property on i=j=1 (see z, m, n) means we can't use order-based.
+//
+// p = 0x 20 21|82 23|84 25 26||
+// q = 0x 20 21|82 23|84 25|86|
+//
+// But keys can still be short from segment 2 to 3, and thus we are violating
+// the common segment prefix property for segment 2 (see n, p, q).
+//
+// Configuration: bytewise comp, BadVarInt0 format for segments 0-3 with
+// segment 3 also continuing to the end of the key. No short key category.
+// x = 0x 80 81|22 83|||
+// y = 0x 80 81|22 83|24 85||
+// z = 0x 80 81|22 83 84|25||
+// m = 0x 80 82|22 83|||
+// n = 0x 80 83|22 84|24 85||
+//
+// Even though this violates the segment maximal prefix property of the
+// simplified model, the common segment prefix property and segment ordering
+// property are satisfied for the various segment ordinals. In broader terms,
+// the usual rule of the delimiter going with the segment before it can be
+// violated if every byte value below some threshold starts a segment. (This
+// has not been formally verified and is not recommended.)
+//
+// Suppose that we are paranoid, however, and decide to place short keys
+// (empty in segment 2) into an unfiltered category. This is potentially a
+// dangerous decision because loss of continuity at least affects the
+// ability to filter on segment 0 (common segment prefix property violated
+// with i=j=0; see z, m, n; m not in category set). Thus, excluding short keys
+// with categories is not a recommended solution either.
 class KeySegmentsExtractor {
  public:
   // The extractor assigns keys to categories so that it is easier to
@@ -269,6 +461,14 @@ class KeySegmentsExtractor {
                        Result* result) const = 0;
 };
 
+// Constructs a KeySegmentsExtractor for fixed-width key segments that safely
+// handles short keys by truncating segments at the end of the input key.
+// See comments on KeySegmentsExtractor for why this is much safer for
+// filtering than "all or nothing" fixed-size segments. This is essentially
+// a generalization of (New)CappedPrefixTransform.
+std::shared_ptr<const KeySegmentsExtractor>
+MakeSharedCappedKeySegmentsExtractor(const std::vector<size_t>& byte_widths);
+
 // Alternatives for filtering inputs
 
 // An individual key segment.
@@ -305,13 +505,13 @@ struct SelectUserTimestamp {};
 
 struct SelectColumnName {};
 
-struct SelectValue {};
-
-// Note: more variants might be added in the future.
+// NOTE: more variants might be added in the future.
+// NOTE2: filtering on values is not supported because it could easily break
+// overwrite semantics. (Filter out SST with newer, non-matching value but
+// see obsolete value that does match.)
 using FilterInput =
     std::variant<SelectWholeKey, SelectKeySegment, SelectKeySegmentRange,
-                 SelectLegacyKeyPrefix, SelectUserTimestamp, SelectColumnName,
-                 SelectValue>;
+                 SelectLegacyKeyPrefix, SelectUserTimestamp, SelectColumnName>;
 
 // Base class for individual filtering schemes in terms of chosen
 // FilterInputs, but not tied to a particular KeySegmentsExtractor.
@@ -336,6 +536,10 @@ std::shared_ptr<SstQueryFilterConfig> MakeSharedBytewiseMinMaxSQFC(
     FilterInput select, KeySegmentsExtractor::KeyCategorySet categories =
                             KeySegmentsExtractor::KeyCategorySet::All());
 
+std::shared_ptr<SstQueryFilterConfig> MakeSharedReverseBytewiseMinMaxSQFC(
+    FilterInput select, KeySegmentsExtractor::KeyCategorySet categories =
+                            KeySegmentsExtractor::KeyCategorySet::All());
+
 // TODO: more kinds of filters, eventually including Bloom/ribbon filters
 // and replacing the old filter configuration APIs