Re: [HACKERS] regression bigtest needs very long time

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) #