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@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +