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 [EMAIL PROTECTED] EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
