2014-08-08 2:13 GMT+02:00 Josh Berkus j...@agliodbs.com:
On 08/07/2014 04:48 PM, Tom Lane wrote:
plpgsql is not efficient at all about coercions performed as a side
effect of assignments; if memory serves, it always handles them by
converting to text and back. So basically the added cost
On 08/05/2014 10:44 PM, Shaun Thomas wrote:
On 08/05/2014 12:56 AM, Mark Kirkwood wrote:
The moral of the story for this case is that mapping Oracle to Postgres
datatypes can require some careful thought. Using 'native' types (like
integer, float8 etc) will generally give vastly quicker
On Thu, Aug 7, 2014 at 5:12 AM, Craig Ringer cr...@2ndquadrant.com wrote:
New Intel hardware supports IEEE 754:2008 decimal floating point in
hardware, and I'm quite interested in implementing DECFLOAT(n) for
PostgreSQL to take advantage of that.
+1
merlin
--
Sent via pgsql-hackers mailing
James Cloos cl...@jhcloos.com writes:
ST == Shaun Thomas stho...@optionshouse.com writes:
ST That said, the documentation here says FLOAT4 is an alias for REAL,
ST so it's somewhat nonintuitive for FLOAT4 to be so much slower than
ST FLOAT8, which is an alias for DOUBLE PRECISION.
There are
On 08/07/2014 04:48 PM, Tom Lane wrote:
plpgsql is not efficient at all about coercions performed as a side
effect of assignments; if memory serves, it always handles them by
converting to text and back. So basically the added cost here came
from float8out() and float4in(). There has been
Hi
I returned to this issue and maybe I found a root issue. It is PL/pgSQL
implicit IO cast
Original text:
postgres=# DO LANGUAGE plpgsql $$ DECLARE n real;
DECLARE f integer;
BEGIN
FOR f IN 1..1000 LOOP
if 0=0 then
n = SQRT (f);
end if;
END LOOP;
RAISE NOTICE 'Result = %',n;
END $$;
Hi
this code is +/- equal to Oracle (it should be eliminate a useless code)
postgres=# DO LANGUAGE plpgsql $$ DECLARE n real;
DECLARE f integer;
BEGIN
FOR f IN 1..1000 LOOP
--if 0=0 then
n = SQRT (f)::real;
--end if;
END LOOP;
RAISE NOTICE 'Result = %',n;
END $$;
NOTICE: Result = 3162.28
DO
ST == Shaun Thomas stho...@optionshouse.com writes:
ST That said, the documentation here says FLOAT4 is an alias for REAL,
ST so it's somewhat nonintuitive for FLOAT4 to be so much slower than
ST FLOAT8, which is an alias for DOUBLE PRECISION.
There are some versions of glibc where doing
2014-08-06 22:07 GMT+02:00 James Cloos cl...@jhcloos.com:
ST == Shaun Thomas stho...@optionshouse.com writes:
ST That said, the documentation here says FLOAT4 is an alias for REAL,
ST so it's somewhat nonintuitive for FLOAT4 to be so much slower than
ST FLOAT8, which is an alias for DOUBLE
Hi
plpgsql has zero optimization for this kind of functions. It is best glue
for SQL statements and relative bad for high expensive numeric
calculations. It is very simple AST interpret only.
Try to use PLPerl, PLPython, PLLua instead for this purposes.
Pavel
2014-08-04 22:48 GMT+02:00
On 05/08/14 17:56, Mark Kirkwood wrote:
Adding in the 'if' in the float8 case increases run time to 4s. So looks
like plpgsql might have a slightly higher cost for handling added
conditionals. Be interesting to dig a bit more and see what is taking
the time.
Thinking about this a bit more,
On Mon, Aug 4, 2014 at 11:48 PM, testman1316 danilo.rami...@hmhco.com wrote:
In both we ran code that did 1 million square roots (from 1 to 1 mill). Then
did the same but within an If..Then statement.
Note: once we started running queries on the exact same data in Oracle and
PostgreSQL we saw
Em segunda-feira, 4 de agosto de 2014, testman1316 danilo.rami...@hmhco.com
escreveu:
SET SERVEROUTPUT ON
SET TIMING ON
DECLARE
n NUMBER := 0;
BEGIN
FOR f IN 1..1000
LOOP
n := SQRT (f);
END LOOP;
In addition to the other suggestions that have been posted (using a
Roberto Mello roberto.me...@gmail.com wrote:
In addition to the other suggestions that have been posted (using
a procedural language more suitable to mathematical ops, etc) I
noticed that you are using a RAISE in the PostgreSQL version that
you are not in Oracle.
I am curious as to what the
On Tue, Aug 5, 2014 at 9:50 AM, Kevin Grittner kgri...@ymail.com wrote:
Since that is outside the loop, the difference should be nominal;
Apologies. I misread on my phone and though it was within the loop.
and in a quick test it was. On the other hand, reducing the
procedural code made a
On 08/05/2014 12:56 AM, Mark Kirkwood wrote:
The moral of the story for this case is that mapping Oracle to Postgres
datatypes can require some careful thought. Using 'native' types (like
integer, float8 etc) will generally give vastly quicker performance.
We've seen a lot of this ourselves.
You are correct sir, 4.1 seconds. Are you a consulant? We ae looking for a
Postgresql guru for advice. We are doing a proof of concept of Postgresql on
AWS
From: Mark Kirkwood-2 [via PostgreSQL]
[mailto:ml-node+s1045698n5813763...@n5.nabble.com]
Sent: Tuesday, August 05, 2014 12:58 AM
To:
We am trying to get an idea of the raw performance of Oracle vs PostgreSQL.
We have extensive oracle experience but are new to PostgreSQL. We are going
to run lots of queries with our data, etc. But first we wanted to see just
how they perform on basic kernel tasks, i.e. math and branching since
On 05/08/14 08:48, testman1316 wrote:
We am trying to get an idea of the raw performance of Oracle vs PostgreSQL.
We have extensive oracle experience but are new to PostgreSQL. We are going
to run lots of queries with our data, etc. But first we wanted to see just
how they perform on basic
19 matches
Mail list logo
