Re: Fixed length data types issue

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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