Re: Reducing the overhead of NUMERIC data
От | Simon Riggs |
---|---|
Тема | Re: Reducing the overhead of NUMERIC data |
Дата | |
Msg-id | 1130968223.8300.1810.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: Reducing the overhead of NUMERIC data (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: