Re: Sun acquires MySQL

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
Cc: "Alex Turner" <armtuk(at)gmail(dot)com>, "Martin Gainty" <mgainty(at)hotmail(dot)com>, walterbyrd <walterbyrd(at)iname(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Sun acquires MySQL
Date: 2008-01-21 18:03:01
Message-ID: 9203.1200938581@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> writes:
> when you use plpgsql as glue of SQL statements, then speed of plpgsql
> speed of SQL statements and there isn't problem. Your example is
> real and I understand well, but bottleneck isn't in interpretation, is
> it in evaluation of basic types, where C do this work simply and fast
> and plpgsql call SQL expression evaluator. I am not sure if its
> possible to write compiler for all supported platforms. I thinking
> about plpgsql->c translator with some intelligence for detecting some
> simply operations. Any sponsors?

That's probably not worth the amount of effort it would take.

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.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Luca Arzeni 2008-01-21 18:26:17 Re: varchar sort ordering ignore blanks
Previous Message Greg Smith 2008-01-21 17:55:27 Re: postgres.org src build vs. enterprisedb installer