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