Re: Fixed length data types issue

Tom Lane wrote:
> After further thought I have an alternate proposal that does that,
> but it's got its own disadvantage: it requires storing uncompressed
> 4-byte length words in big-endian byte order everywhere. This might
> be a showstopper (does anyone know the cost of ntohl() on modern
> Intel CPUs?), but if it's not then I see things working like this:
>
> * If high order bit of datum's first byte is 0, then it's an
> uncompressed datum in what's essentially the same as our current
> in-memory format except that the 4-byte length word must be big-endian
> (to ensure that the leading bit can be kept zero). In particular this
> format will be aligned on 4- or 8-byte boundary as called for by the
> datatype definition.
>
> * 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

Great. I assumed we would have to use a variable-length header, as you
described. I don't think ntohl() is going to be a problem.

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +