Expand description
The string representation.
spec/07-execution.md section 7.1: a string is a 16 byte structure, 4 bytes of length, 4 bytes
of prefix, and 8 bytes that are either the rest of a short string or a way to find a long one.
Strings of 12 bytes or fewer live entirely inside the structure. The prefix means most
comparisons and most equality tests answer without dereferencing anything, which on the string
heavy queries in ClickBench is the difference between a cache hit and a cache miss per row.
Where this differs from the specification, and why. The document says the last 8 bytes are
a pointer, which is what DuckDB and Umbra do. Here they are a block index and an offset, which
is what Arrow’s StringView does. The sizes are identical, the prefix trick is identical, and
the prefix trick is the part that makes it fast. The difference is one predictable load against
one pointer chase on the slow path only, and in exchange the whole representation is safe code
with no pinning machinery, which does not exist until the buffer manager arrives at M2. This is
the kind of decision that gets remeasured rather than argued about, and it is tracked as an
issue so that M3 measures it instead of inheriting it.
Structs§
- String
Column - A column of strings: the views, and the blocks the long ones live in.
- String
View - A 16 byte handle on a string.
Constants§
- INLINE_
LIMIT - The longest string that fits entirely inside a view.