I wrote: > Gregory Stark <[EMAIL PROTECTED]> writes: >> Anything shorter than the shortest possible numeric representation can >> implicitly be interpreted as some alternate compact representation. I >> already had a patch that stored small integers in a single >> NumericDigit without any numeric header at all.
> That's getting well beyond the realm of reason IMHO. I doubt you can > merge it with this proposal anyway --- how will you disambiguate from > zero with a positive dscale ("0.00")? Hmm, I take that back: it could be merged with this proposal pretty easily. Again assuming that we move the POS/NEG/NAN/SHORT "sign" flags to the first header word, we can have: Sign=NAN: it's a NAN, regardless of anything else. We may as well store NAN as just 2 bytes. Sign=SHORT: it's a non-NAN with limited weight and dscale range, as per my proposal. A zero value would still be only 2 bytes, but anything else is longer. (This would be needed only for zero with nonzero dscale, though.) Sign=POS or NEG: if length == 2 bytes then interpret the remaining 14 bits as a single NBASE digit, with assumed weight and dscale 0. This allows storing integers up to +/-9999 in 2 bytes (+ 1 byte varlena header). If length > 2 then it is a traditional-format numeric. I'm not entirely convinced this is worth the extra pack/unpack logic, since said integers would be 4 bytes (+1 byte header) in the sign=SHORT representation, which is not that much more. Also, this means at least three different representations of some values, which is going to be a headache for comparison and hashing. But the bit-space is there. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate