Bruce Momjian <[EMAIL PROTECTED]> writes: > * Consider ways of storing rows more compactly on disk > o Support a smaller header for short variable-length fields?
With respect to the business of having different on-disk and in-memory representations, we have that already today: see TOAST. It strikes me that it might be useful to think about solving the problem with a "second generation toast mechanism". The first generation only worried about storing large values, but the second generation would also address the problem of storing small values efficiently. Or you could think about it as a "second generation varlena". This mindset would make for a slightly different set of choices about where the work gets done. I'm not sure which is better. Either way, I think it would be interesting to consider (a) length word either one or two bytes, not four. You can't need more than 2 bytes for a datum that fits in a disk page ... (b) alignment either one or two bytes, not four. TEXT would be perfectly happy with 1-byte alignment, but for NUMERIC we might want 2. I'm inclined to bag the idea of storing the length words separately from the data proper. Although it probably would make for some marginal gain in cache efficiency, I don't see any reasonable way at all to fit it into the current system structure, whereas either the "toast" or "next gen varlena" approaches seem fairly straightforward. And having to track an additional pointer inside the inner loops of heap_form_tuple and heap_deform_tuple could eat up any performance gain anyway. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster