On Wed, 2005-11-02 at 15:09 -0500, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> 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.)
OK
> 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.
Well, that certainly is obscure, I'll give you that. 308 huh?
The middle ground between 64 and 308 is somewhere around 255, yes? :-)
I'll get on it. Including Catch-308.
Best Regards, Simon Riggs
