A table gives each column its own type — in what three ways can the values behind one column actually be held?

## The logical picture hides the storage In a **labelled table** — a rectangle whose columns are named and typed one at a time, and whose rows may or may not carry an identity of their own — every field declares one **column representation**: the single physical form every value in it is stored in. That sentence is about typing. It does not say whether the field is one allocation, several, or part of a bigger one, and those are three genuinely different designs shipping in this family today. This matters because almost every cost claim people make about a table is really a claim about the storage, dressed up as a claim about the logical column. ## One run per field The field is a single allocation holding its values back to back. - There is a buffer, and you can point at it. Anything that wants the field contiguously already has it. - Adding a field is one new allocation and does not read any existing field. - Appending records has to make room in **every** field's run, which can mean allocating a bigger one and copying what was already there. - The field owns its memory: freeing it frees the values. ## A chunked column The field is held as an ordered sequence of separately allocated runs rather than as one buffer. - Appending a batch of records is one more chunk per field and copies nothing that already exists. This is the case where "appending rows is expensive" is weakest. - There is no single buffer. Handing the field to a consumer that demands contiguity means allocating a new run and copying every chunk into it. - Anything sweeping the field crosses chunk boundaries, so the sweep is a loop over runs rather than one run. - Appending **one record at a time** is the failure mode: you get a long sequence of tiny chunks, and everything downstream pays for the fragmentation. ## One slab per representation Every field sharing a representation is packed into a single two-dimensional allocation, and a field is a slice of it. - Operations touching all the same-representation fields at once are a single pass over one allocation. - A field does not own its memory. The slab stays alive as long as any slice of it does, so dropping one field frees nothing on its own. - Adding another field of a representation the slab already holds may mean allocating a bigger slab and copying the existing fields into it — the one case where a field add is the *expensive* direction. - Whether the slice itself is contiguous depends on the slab's own layout; where the slab runs field by field, the slice is contiguous and can be handed out as a window. ## Side by side | | one run per field | chunked field | slab per representation | |---|---|---|---| | is the field one allocation? | yes, and it owns it | no, a sequence of them | it is a slice of a shared one | | append a batch of records | make room in every run | one more chunk per field | extend or rebuild the slab | | add a new field | one allocation | one allocation | may rebuild the whole slab | | hand out a contiguous buffer | already available | allocate and copy | available if the slab runs field by field | | drop one field | frees its values | frees its chunks | frees nothing until the slab goes | ## Why you should not assume The sentence *"a table stores each column as one contiguous run of values"* is the single most commonly asserted thing in this subject and it is true of exactly one of the three. Two habits follow from that: 1. **Attach the precondition to the claim.** "Appending a batch is cheap" is a statement about a chunked holding. "Adding a field is one allocation" is a statement about the two non-consolidating holdings. Said flat, each one is wrong somewhere. 2. **Measure rather than reason, when the cost matters.** The holdings are not visible from the logical picture, so the way to find out which one you are on is to time the operation you care about as the table gets wider and as it gets longer, and see which dimension the cost tracks. ## What this does not decide The storage decides physical costs, not semantics. The same table, the same field names, the same values and the same per-field forms are on offer in all three; what changes is which operations are an allocation, which are a copy, and which are free. Keep the two apart in your own explanations, because an interviewer asking "what does that cost?" is asking about the storage, and an interviewer asking "what will it return?" is not.