Re: Sun acquires MySQL

Tom Lane wrote:
> The bottom line is: if you're doing computationally expensive
> non-SQL-query operations, plpgsql is simply the wrong language for the
> job ... and it's not like there are not plenty of others to choose from.
> I'd expect plperl or even pltcl to be faster for such things (I have no
> idea about the speed of other scripting languages such as python or
> ruby).  Or pl/java.  Also, if what you're doing fits within its
> capabilities, pl/R is an interesting alternative.

Unfortunately, I think the stored procedure implementation in PG itself
introduces significant overhead.  See thread "Writing most code in
Stored Procedures" from August 2007.  I converted an application from
that BigDBMS we are not allowed to mention to PG.  Code is Java, stored
procs were written in PL/Java.  On the exact same hardware, I couldn't
get any where near the throughput I was getting in BigDBMS.  The procs
are trivial - just wrappers for insert statements.  After I exhausted
all alternatives, I replaced the stored proc invocation in the code with
inserts.  Then, PG was able to achieve the same throughput as BigDBMS.

--
Guy Rouillier