Tom Lane wrote:
>
> Michael Robinson <robinson@netrinsics.com> writes:
> > The question, though, becomes what percentage of operations on a
> > NUMERIC field are arithmetic, and what percentage are storage/retrieval.
>
> Good point.
>
> > For databases that simply store/retrieve data, your "optimization" will have
> > the effect of significantly increasing format conversion overhead. With a
> > 512-byte table, four packed-decimal digits can be converted in two
> > primitive operations, but base-10000 will require three divisions,
> > three subtractions, four additions, plus miscellaneous data shuffling.
>
> That is something to worry about, but I think the present implementation
> unpacks the storage format into calculation format before converting
> to text. Getting rid of the unpack step by making storage and calc
> formats the same would probably buy enough speed to pay for the extra
> conversion arithmetic.
What I'm actually wondering about is why the hell using
NUMERIC data type for fields where the database shouldn't
calculate on. Why not using TEXT in that case?
OTOH, I don't think that the format conversion base 10000->10
overhead will be that significant compared against what in
summary must happen until one tuple is ready to get sent to
the frontend. Then, ALL our output functions allocate memory
for the string representation and at least copy the result to
there. How many arithmetic operations are performed
internally to create the output of an int4 or float8 via
sprintf()?
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) #
