Gregory Stark <[EMAIL PROTECTED]> writes: > Tom Lane <[EMAIL PROTECTED]> writes: >> I'm imagining that it would give you the same old uncompressed in-memory >> representation as it does now, ie, 4-byte length word and uncompressed >> data.
> Sure, but how would you know? Sometimes you would get a pointer to a varlena > starting with a bytes with a leading 00 indicating a 1-byte varlena header and > sometimes you would get a pointer to a varlena with the old uncompressed > representation with a 4-byte length header which may well start with a 00. Yeah, in that scheme you need some out-of-band information telling you if the datum is compressed or not. The second scheme I posted avoids that problem. >> * If high order bit of first byte is 1, then it's some compressed >> variant. I'd propose divvying up the code space like this: >> >> * 0xxxxxxx uncompressed 4-byte length word as stated above >> * 10xxxxxx 1-byte length word, up to 62 bytes of data >> * 110xxxxx 2-byte length word, uncompressed inline data >> * 1110xxxx 2-byte length word, compressed inline data >> * 1111xxxx 1-byte length word, out-of-line TOAST pointer > I'm unclear how you're using the remaining bits. Length (or high order bits of it, if the length covers more than 1 byte). > Also Heikki points out here that it would be nice to allow for the case for a > 0-byte header. I don't think there's enough code space for that; at least not compared to its use case. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq