Roland Bouman wrote:
Hi!
On Fri, Oct 30, 2009 at 10:45 PM, Sheeri K. Cabral <[email protected]> wrote:
In general, I'm OK with dropping DECIMAL as a built-in type. (just
try to calculate storage of a DECIMAL type! It's very annoying).
???
I don't understand....perhaps this is incredibly ignorant but isn't
throwing decimal out alltogether a bit too much?
I mean, decimal is the only datatype that deals with fixed precision
fractions, right?
Suppose I'd want to do something with monetary amounts...do you
suggest to scale those up and store them as integers?
I don't really mind what library sits behind it, but I think having a
reliable fixed precision fractional number type is a pretty essential
feature.
The decimal type is a real mess. It consists of two decimal integers:
One representing everything to the left of the decimal point, other the
the digits to the right. Each is storage in a variable length vector of
32 bit words, but each word only contains up to 9 decimal digits worth
of precision. And it can't be parsed without knowing the specifics of
the definition.
The claim to fame for the representation is that it can be compared to
identical types bytewise. Any other comparisons require decoding.
The split between the left and right side of the decimal point is
utterly mindless, designed, perhaps, by somebody out sick during 4th
grade.
Falcon converts the external decimal type to a decimally scaled,
variable length vector of unsigned 32 bit integers. The scale and sign
are stored separately.
I did some fairly exhaustive performance comparison between the Falcon
classes and the equivalent MySQL functions. The worst case (best for
MySQL, worst for Falcon) showed a 2:1 difference in performance favoring
Falcon. However, since Falcon stored all integers below 2**63 as int64s
or int32s, the more common difference was more like 20:1.
Performance of "decimal" is critical since just about every
representation of money contains a decimal fraction. For plausible
amounts of currency, using a binary number with a decimal scale factor
is vastly faster than the MySQL decimal type.
The high precision (>21 decimal digits) is necessary to execute the DBT2
/ TPCC benchmark, so there is no escape.
There is a persistent belief among programmers that a decimal scale
factor on a binary number is unkosher. There were, apparently, a lot of
future programmers out sick during 4th grade. My first encounter was a
summer job in high school working for a TV rating company in 360
assembler. Looking over a colleagues code, I noticed that to add two
numbers already in registers to converted each to packed decimal, added
them, and converted the result back to binary. When I asked why he went
through all that trouble, he explained that the numbers were originally
decimal, so binary addition wouldn't work. I had a very similar
discussion with a guy on Rdb/VMS with a masters in computer science.
Numeric with a decimal scale factor is important. So is near-arbitrary
precision numeric. But not all scaled numeric needs to be arbitrary
precision binary.
Note: This would be a good excuse to implement a value object.
--
Jim Starkey
Founder, NimbusDB, Inc.
978 526-1376
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
