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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
