Gregory Stark <[EMAIL PROTECTED]> writes: > Tom Lane <[EMAIL PROTECTED]> writes: >> (1) code written to existing practice will always generate 4-byte >> headers. (Hence, VARDATA() acts the same as now.) That's the format >> that generally gets passed around in memory.
> So then we don't need to replace VARSIZE with SET_VARLENA_LEN at all. Yes, we do, because we have to alter the representation of 4-byte headers. Otherwise we can't tell which header format a datum is using. > So (nigh) every tuple will get deformed and reformed once before it goes to > disk? Currently the toast code doesn't even look at a tuple if it's small > enough, but in this case we would want it to fire even on very narrow rows. I'd be inclined to put the intelligence into heap_form_tuple and thereby avoid getting the TOAST code involved unless there are wide fields to deal with. > What I had had in mind was to prohibit using smaller headers than the > alignment of the data type. But that was on the assumption we would continue > to use the compressed header in memory and not copy it. Well, it wouldn't be too unreasonable to limit this whole mechanism to datatypes that have no alignment requirements on the *content* of their datums; which in practice is probably just text/varchar/char and perhaps inet. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate