Tom Lane wrote: > Gregory Stark <[EMAIL PROTECTED]> 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 text path 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 [EMAIL PROTECTED] EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend