On 09/02/2014 09:08 AM, Pavel Stehule wrote:
JavaScript would actually be quite a good alternative. However,
using it involves something others have objected to, namely
calling SQL via a function call. It's true that plpgsql lets you
call SQL commands without explicitly invoking SPI. OTOH, it
actually relies on SPI under the hood a lot more that other PLs,
which I have little doubt is responsible for timings like this:
andrew=# do $$ declare x int = 1; i int = 1; begin while i <
10000000 loop i := i + 1; x := x + 46; end loop; raise notice ' x =
%',x; end; $$;
NOTICE: x = 459999955
DO
Time: 13222.195 ms
andrew=# do $$ var x = 1; var i = 1; while (i < 10000000) { i += 1;
x += 46; } plv8.elog(NOTICE, "x = " + x); $$ language plv8;
NOTICE: x = 459999955
DO
Time: 27.976 ms
this test is unfair to plpgsql, and you know it well :)
any operations over native types will be faster than in plpgsql,
although this difference is maybe too much. Doesn't use
--enable-cassert ?
It's not unfair, and no it isn't using cassert. This was from a
production grade server.
PLV8 has its own issues (see discussion elsewhere in this thread re
int64 and numeric). It's just that speed isn't one of them :-)
Please note that I'm not unhappy with plpgsql. I have my own small list
of things that I would like improved, but there isn't very much that
bugs me about it.
A few years ago I was largely instrumental in building an entire billing
system, including some very complex tax rating, for a small Telco, using
plpgsql plus a tiny bit of plperlu glue where we needed unsafe
operations. It was quite fast enough - see my talk at pgopen a few years
back.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
