On Mon, Nov 02, 2009 at 04:42:10PM -0500, Jim Starkey wrote: > The claim to fame for the representation is that it can be compared > to identical types bytewise. Any other comparisons require > decoding.
Which is casually nice for not writing more code in indexing in the engine.... but for 99% of engines, is calling a comparison function that much harder? Probably not. I'm also against weird-ass stuff such as having INT24 indexing still around just for DATE. Overloading stuff, not nice. Inheritance++ > 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. I am 142.74% in favor of going towards this representation. -- Stewart Smith _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
