If you try it with max() you'd likely get less-surprising answers.
So it was in fact the type conversions that got timed.
Damn. I got outsmarted XDD
Rewind :
CREATE TEMPORARY TABLE test AS SELECT a::FLOAT AS f,
(a::NUMERIC)*100 AS n, a::INTEGER AS i, a::
Vincenzo Romano <[EMAIL PROTECTED]> writes:
> It sounds quite strange to me that numeric is faster than bigint.
This test is 100% faulty, because it fails to consider the fact that the
accumulator used by sum() isn't necessarily the same type as the input
data. In fact we sum ints in a bigint and
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
sh
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 ve
Hmmm ...
It sounds quite strange to me that numeric is faster than bigint.
Even if bigint didn't get hw support in the CPU it should have been
faster that numeric as it should be mapped in 2 32-bits integers.
Numeric algorithms should be linear (according to the number of digits) in
complexity w
It is. But why do you care? You either have the correctness that
NUMERIC gives, or you don't.
I suspect it's still useful to know what order of magnitude slower it
is. After all if it is 1000x slower (not saying it is), some people may
decide it's not worth it or roll their own.
Any hint
At 01:42 AM 6/1/2007, Alvaro Herrera wrote:
Vincenzo Romano escribió:
> Hi all.
> I'd like to know whether there is any "real world" evaluation (aka test) on
> performances of the NUMERIC data type when compared to FLOAT8 and FLOAT4.
> The documentation simply says that the former
is "much slowe
On Thu, May 31, 2007 at 09:25:27PM +0200, Vincenzo Romano wrote:
> On Thursday 31 May 2007 19:42:20 Alvaro Herrera wrote:
> > It is. But why do you care? You either have the correctness that
> > NUMERIC gives, or you don't.
>
> Because FLOAT8 can be precise enough for some application and not
>
On Thursday 31 May 2007 19:42:20 Alvaro Herrera wrote:
> It is. But why do you care? You either have the correctness that
> NUMERIC gives, or you don't.
Because FLOAT8 can be precise enough for some application and not
enough for other ones.
--
Vincenzo Romano
--
Maybe Computer will never beco
Vincenzo Romano escribió:
> Hi all.
> I'd like to know whether there is any "real world" evaluation (aka test) on
> performances of the NUMERIC data type when compared to FLOAT8 and FLOAT4.
> The documentation simply says that the former is "much slower" than the latter
> ones.
It is. But why do
10 matches
Mail list logo
