A serialised page consists of either a single disk page or several disk pages. The latter is a primary page followed by one or more overflow pages. Each disk page (single or multi) uses the same DiskPageSize, which should be known from context (e.g. configuration).

A serialised page fits within chunks of memory of 4k, 8k, 16k, 32k or 64k.

If a page uses overflow pages, return the:

1. value prefix length (within the first page)
2. value suffix length (within the overflow pages)

The total number of disk pages, including any overflow pages.

Convert from PageContentFits (from the reference implementation) to RawPage (from the real implementation).

A test case consisting of a key/operation sequence that is guaranteed to either fit into a single 4k disk page, or be a single entry that spans a one primary 4k disk page and zero or more overflow disk pages.

The keys are not ordered.

A test case consisting of a key/operation sequence that is guaranteed to either fit into a single 4k disk page, or be a single entry that spans a one primary 4k disk page and zero or more overflow disk pages.

The keys are in strictly ascending order.

Strictly increasing, so no duplicates.

A test case consisting of a key/operation sequence that is not guaranteed to fit into a a 4k disk page.

These test cases are useful for checking the boundary conditions for what can fit into a disk page.

The keys are not ordered.

A tests case consisting of a single key/operation pair.

Generate a test case consisting of a key/operation sequence that is guaranteed to fit into a given disk page size.

The distribution is designed to cover:

• small pages
• medium sized pages
• nearly full pages
• plus single key pages (possibly using one or more overflow pages)
• a corner case of a single large key/operation pair followed by some small key op pairs.

The keys are not ordered: use orderdKeyOps to sort and de-duplicate them if that is needed (but note this will change the order of key sizes).

Generate a test case consisting of a key/operation sequence that is not guaranteed to fit into a given disk page size.

These test cases are useful for checking the boundary conditions for what can fit into a disk page. This covers a similar distribution to genPageContentFits but also includes about 20% of pages that are over full, including the corner case of a large key ops pair followed by smaller key op pairs (again possibly over full).

The keys are not ordered: use orderdKeyOps to sort and de-duplicate them if that is needed.

Generate a test case consisting of a single key/operation pair.

Generate only pages that are nearly full. This isn't the maximum possible size, but where adding one more randomly-chosen key/op pair would not fit (but perhaps a smaller pair would still fit).

Consider if you really need this: the genPageContentMedium also includes these cases naturally as part of its distribution. On the other hand, this can be good for generating benchmark data.

This generates a reasonable "middle" distribution of page sizes (relative to the given disk page size). In particular it covers:

• small pages (~45% for 4k pages, ~15% for 64k pages)
• near-maximum pages (~20% for 4k pages, ~20% for 64k pages)
• some in between (~35% for 4k pages, ~60% for 64k pages)

The numbers above are when used with the normal arbitrary Key and Value generators. And with these generators, it tends to use lots of small-to-medium size keys and values, rather than a few huge ones.

In some use cases it is necessary to generate Keys that are at least of some minimum length. Use noMinKeySize if no such constraint is need.

No minimum key size: MinKeySize 0.

Sort and de-duplicate a key/operation sequence to ensure the sequence is strictly ascending by key.

If you need this in a QC generator, you will need shrinkOrderedKeyOps in the corresponding shrinker.

Shrink a key/operation sequence (without regard to key order).

Shrink a key/operation sequence, preserving key order.