>
> > Bruce Momjian wrote:
> >
> > > Oh, I didn't realize this. We certainly should think about reducing the
> > > time spent on it, though it is kind of lame to be testing numeric in a
> > > precision that is less than the standard int4 type.
> >
> > We certainly should think about a general speedup of NUMERIC.
>
> How would we do that? I assumed it was already pretty optimized.
By reimplementing the entire internals from scratch again :-)
For now the db storage format is something like packed
decimal. Two digits fit into one byte. Sign, scale and
precision are stored in a header. For computations, this gets
unpacked so every digit is stored in one byte and all the
computations are performed on the digit level and base 10.
Computers are good in performing computations in other bases
(hex, octal etc.). And we can assume that any architecture
where PostgreSQL can be installed supports 32 bit integers.
Thus, a good choice for an internal base whould be 10000 and
the digits(10000) stored in small integers.
1. Converting between decimal (base 10) and base 10000 is
relatively simple. One digit(10000) holds 4 digits(10).
2. Computations using a 32 bit integer for carry/borrow are
safe because the biggest result of a one digit(10000)
add/subtract/multiply cannot exceed the 32 bits.
The speedup (I expect) results from the fact that the inner
loops of add, subtract and multiply will then handle 4
decimal digits per cycle instead of one! Doing a
1234.5678 + 2345.6789
then needs 2 internal cycles instead of 8. And
100.123 + 12030.12345
needs 4 cycles instead of 10 (because the decimal point has
the same meaning in base 10000 the last value is stored
internally as short ints 1, 2030, 1234, 5000). This is the
worst case and it still saved 60% of the innermost cycles!
Rounding and checking for overflow will get a little more
difficult, but I think it's worth the efford.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
