Re: Reducing data type space usage

Gregory Stark wrote:
> Case 2) Data types that are different sizes depending on the typmod but are always
>    the same size that can be determined statically for a given typmod. In the
>    case of a ASCII encoded database CHAR(n) fits this category and in any case
>    we'll eventually have per-column encoding. NUMERC(a,b) could also be made
>    to fit this as well.
>    
>    In cases like these we don't need *any* varlena header. If we could arrange
>    for the functions to have enough information to know how large the data
>    must be.

I thought about the CHAR(1) case some more.  Rather than restrict
single-byte storage to ASCII-encoded databases, I think there is a more
general solution.

First, I don't think any solution that assumes typmod will be around to
help determine the meaning of the column is going to work.

I think what will work is to store a 1-character, 7-bit ASCII value in
one byte, by setting the high bit.  This will work for any database
encoding.  This is the zero-length header case.

If the 1-character has a high bit, will require a one-byte length header
and then the high-bit byte, and if it is multi-byte, perhaps more bytes.

Zero-length header will even work for a VARCHAR(8) field that stores one
7-bit ASCII character, because it isn't relying on the typmod.

FYI, we also need to figure out how to store a zero-length string.  That
will probably be high-bit, and then all zero bits.  We don't store a
zero-byte in strings, so that should be unique for "".

--  Bruce Momjian   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +