>>> >>>The only time it's possible to have millions of floating >>>points operations per second is while a nice >>>SUM(amount_sold) on the large fact table is running. Is amount_sold a 10g BINARY_FLOAT or BINARY_DOUBLE? If not that would not be fpu and the number of integer ops between each amount_sold++ far far far outweighs the cost of using scaled integer math. If the datatype is not BINARY_FLOAT or BINARY_DOUBLE, contrast the summation results from that SQL aggregation to the result you get if you pull that data out and cast it into a C floating point type and sum it there. Of course, amount_sold would unlikely require 38 digits of precision so the result should be the same....unless the dollar keeps dropping I guess. BTW, I'm not sure the new BINARY_FLOAT datatype actually guarantees it will be mashed with the FPU. The docs only say it _can_ be so. Knowing Oracle, there is likely a port-level action to make it so. -- //www.freelists.org/webpage/oracle-l