Tom Lane wrote:
> Gregory Stark <stark@enterprisedb.com> writes:
> > The user would have to decide that he'll never need a value over 127 bytes
> > long ever in order to get the benefit.
>
> Weren't you the one that's been going on at great length about how
> wastefully we store CHAR(1) ? Sure, this has a somewhat restricted
> use case, but it's about as efficient as we could possibly get within
> that use case.
To summarize what we are now considering:
Originally, there was the idea of doing 1,2, and 4-byte headers. The
2-byte case is probably not worth the extra complexity (saving 2 bytes
on a 128-byte length isn't very useful).
What has come about is the idea of 0, 1, and 4-byte headers. 0-byte
headers store only one 7-bit ASCII byte, 1-byte headers can store 127
bytes or 127 / max_encoding_len characters. 4-byte headers store what
we have now.
The system is split into two types of headers, 0/1 headers which are
identified by a special data type (or mapped to a data type that can't
exceed that length, like inet), and 4-byte headers. The code that deals
with 0/1 headers is independent of the 4-byte header code we have now.
I am slightly worried about having short version of many of our types.
Not only char, varchar, and text, but also numeric. I see these varlena
types in the system:
test=> SELECT typname FROM pg_type WHERE typlen = -1 AND typtype = 'b' AND typelem = 0; typname----------- bytea
textpath polygon inet cidr bpchar varchar bit varbit numeric refcursor(12 rows)
Are these shorter headers going to have the same alignment requirements
as the 4-byte headers? I am thinking not, meaning we will not have as
much padding overhead we have now.
-- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +