From: | Mark Butler <butlerm(at)middle(dot)net> |
---|---|
To: | mweilguni(at)sime(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: NUMERIC type benchmarks - CORRECTED |
Date: | 2001-04-16 00:26:43 |
Message-ID: | 3ADA3C43.A0752822@middle.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Mario Weilguni wrote:
> I tested that on a similar configuration (P-III 450) and got the same
> results. When the addition is removed from the loop and replaced with a
> simple assignment, the total execution time goes down to ~6.5 seconds. That
> means that the modified numeric is nearly twice as fast, sure worth
> considering that.
I am embarrassed to admit I had an undeleted overloaded function that caused
me to time the wrong function. The correct numbers should be:
Postgres PL/PGSQL original numeric: 14.8 seconds
Postgres PL/PGSQL modified numeric: 14.0 seconds
Postgres PL/PGSQL float8: 10.7 seconds
GNU AWK: 2.5 seconds
Oracle PL/SQL number: 2.0 seconds
This means that Tom Lane was absolutely right - for the current numeric type
implementation, palloc() overhead is not a dominant concern. A serious
solution needs to change the internal format to use a larger base, as Tom
suggested.
- Mark Butler
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Butler | 2001-04-16 00:38:52 | Int64 (long long) Supporting Compiler Requirement Status? |
Previous Message | Bruce Momjian | 2001-04-15 18:18:47 | Re: Fast Forward (fwd) |