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