Re: PL/pgSQL 2

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