Simon Riggs <[EMAIL PROTECTED]> writes:
> I wasn't trying to claim the bit assignment made sense. My point was
> that the work to mangle the two fields together to make it make sense
> looked like it would take more CPU (since the standard representation of
> signed integers is different for +ve and -ve values). It is the more CPU
> I'm worried about, not the wasted bits on the weight.
I think that's purely hypothetical. The existing representation, as
well as the one you propose, both require shift-and-mask operations
to pull the fields out of the packed format. The format I'm suggesting
would require some different shift-and-mask operations. As a first
approximation it'd be a wash, and any actual differences would be
CPU-specific enough that we shouldn't put a whole lot of weight on the
point. (C compilers tend to be fairly bright about optimizing field
extraction operations.)
Moreover, you've forgotten the basic gating factor here, which is
whether such a proposal will get accepted at all. Reducing the
available range from 1000 digits to 255 might pass without too much
objection, but dropping it down another factor of 4 to 63 starts to
bring it uncomfortably close to mattering to people.
[ thinks for a moment... ] Actually, neither proposal is going to get
off the ground, because the parser's handling of numeric constants is
predicated on the assumption that type NUMERIC can handle any valid
value of FLOAT8, and so we can get away with converting to NUMERIC on
sight and then coercing to float later if parse analysis finds out the
constant should be float. If the dynamic range of NUMERIC is less than
10^308 then this fails. So we have to find another bit somewhere, or
the idea is dead in the water.
regards, tom lane
---------------------------(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
