I'm getting more confused.
If the algorithm used to do the sum is a drop in the sea,
then the resources needed to pass a pointer on the stack are
a molecule in the drop! :-)
Nonetheless I think that your directions are right:
doing actual queries instead of inspecting the algorithms themselves
should yeld numbers that are (by definition) coherent with real world usage!
Another point is related to storage.
I think that as far as the storage for a numeric is within few bytes, the
difference should be related only to the algorithm.
But with larger size, you have no option with floats!
So, finally, the question should have been:
When used in the same ranges as FLOAT8 or FLOAT, what'd be the performance
impact of NUMERIC?
Sorry for having been unclear. And thanks for the hints.
On Monday 04 June 2007 13:17:49 PFC wrote:
> This is a 32 bit CPU by the way.
>
> Consider this :
>
> - There are 100K rows
> - The CPU executes about 3 billion instructions per second if everything
> is optimum
> - "SELECT sum(n) FROM test", takes, say 60 ms
>
> This gives about 1800 CPU ops per row.
> A Float addition versus an Int addition is a drop in the sea.
>
> I believe the marked difference between Floats/Ints (faster) and
> Numeric/Bigint (slower) comes from being passed by value or by pointers.
>
> A single access which misses the CPU cache and has to go fetch data from
> the real RAM spends a lot more cycles than the simple loops in a NUMERIC
> addition which will hit L1 cache.
> Nowadays cache access patterns matter more than how many actual CPU
> instructions are executed...
>
> >> forum_bench=> SELECT sum(i) FROM test;
> >> Temps : 46,589 ms
> >> forum_bench=> SELECT sum(f) FROM test;
> >> Temps : 63,865 ms
> >>
> >> forum_bench=> SELECT sum(b) FROM test;
> >> Temps : 157,018 ms
> >> forum_bench=> SELECT sum(n) FROM test;
> >> Temps : 124,816 ms
--
Vincenzo Romano
--
Maybe Computer will never become as intelligent as Humans.
For sure they won't ever become so stupid. [VR-1988]
