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
       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
       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.



Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to