From: | Michael Robinson <robinson(at)netrinsics(dot)com> |
---|---|
To: | pgsql-hackers(at)hub(dot)org |
Subject: | Re: [HACKERS] regression bigtest needs very long time |
Date: | 1999-06-30 02:23:22 |
Message-ID: | 199906300223.KAA02554@netrinsics.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
wieck(at)debis(dot)com (Jan Wieck) writes:
>> > We certainly should think about a general speedup of NUMERIC.
>>
>> How would we do that? I assumed it was already pretty optimized.
>
> 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!
The question, though, becomes what percentage of operations on a
NUMERIC field are arithmetic, and what percentage are storage/retrieval.
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.
-Michael Robinson
From | Date | Subject | |
---|---|---|---|
Next Message | Vadim Mikheev | 1999-06-30 02:28:46 | Re: [HACKERS] Hot Backup Ability |
Previous Message | Todd Graham Lewis | 1999-06-30 02:10:41 | Re: [HACKERS] Hot Backup Ability |