Expand description
The bytes a key map takes in a section payload.
spec/graph/03-the-file-format.md section 3.3 asks for a fixed header carrying what the build
observed, then the form’s own payload. This module is that layout and nothing else: it does not
know what a section is, what an extent is or where in a file the bytes go, because
rudb-native is the crate that knows those and it is above this one.
The header is forty bytes and not the twenty four section 3.3 quotes. Three reasons, and the
difference is worth naming rather than quietly absorbing. base has to be an i128 because a
key can be a HUGEINT or a dictionary code and a key map that could not hold one would be a
key map with an exception in it. The null count has to be there because a null is not a key and
the row count alone does not say how many rows the column had. And section 3.3 also requires
the four observed facts in the header, which is where distinctness and sortedness live. Forty
bytes against twenty four, on the six TPC-H tables that take the identity form, is ninety six
bytes in total, so the fidelity that would be lost by padding it back down is worth more than
the bytes.
What the header does not hold is the maximum key, because every form derives it: identity from the count, dense from the range, sorted from its last stored key. A number stored twice is a number that can disagree with itself.
Structs§
- Payload
- A key map’s bytes, ready to be split into extents and written.
Constants§
- HEADER_
BYTES - Bytes of fixed header at the front of a key map payload.