DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=Yahoo.com;
	h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=DXpq4FHkUnihgkzp6d3oABlC23SUkAwuZ/6P7zSk2HWUqdZtzZWPQFx6s639et6xqsIM1hD6kh37fd/AYRZHxqo1qf80UK+TIvClZJZRN1zu268hnOrga1bx8rFUig6gmImRlRRWYq6nULS8R6XGC2jITZaRsw0uSj1hdnEvlWg=
	;
Message-ID: <435F928E.1080408@Yahoo.com>
Date: Wed, 26 Oct 2005 10:28:30 -0400
From: Jan Wieck <JanWieck@Yahoo.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.1) Gecko/20040707
MIME-Version: 1.0
To: "Marc G. Fournier" <scrappy@postgresql.org>
Cc: Michael Fuhr <mike@fuhr.org>, pgsql-sql@postgresql.org
Subject: Re: pl/* overhead ...
References: <20051026005729.V993@ganymede.hub.org>
	<20051026065542.GA19386@winnie.fuhr.org>
	<20051026064246.Q993@ganymede.hub.org>
In-Reply-To: <20051026064246.Q993@ganymede.hub.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

PL/pgSQL is as *internal* as for example PL/Tcl. The two are actually 
pretty similar and I would expect them to perform similar, if one knows 
what and how he does.

PL/pgSQL is an external shared object, loaded on call of the first func 
per backend. Same for PL/Tcl.

PL/pgSQL takes pg_proc.prosrc and compiles all control structures (if, 
else, loop) into a form of bytecode. Query strings are left alone until 
the statements are actually executed. Tcl has a similar concept of 
bytecode compilation.

PL/pgSQL turns all expressions and SQL statements into prepared SPI 
plans. It short-circuits simple expressions by directly calling the node 
execution, so it works with PostgreSQL's native types and operators. 
Here is the big difference, PL/Tcl turns all datums into their external 
string representations and then does the Tcl dual-ported-object munging 
and math. However, if used right it also offers prepared SPI plans.

If the implementation of functionality results in widely similar code, I 
would expect PL/pgSQL and PL/Tcl to perform similar. However, doing the 
prepared SPI stuff in Tcl is a bit of work. OTOH doing extensive string 
processing in PL/pgSQL is a nightmare. That difference should drive the 
decision which language to use when.


Jan


On 10/26/2005 5:48 AM, Marc G. Fournier wrote:

> On Wed, 26 Oct 2005, Michael Fuhr wrote:
> 
>> On Wed, Oct 26, 2005 at 12:58:13AM -0300, Marc G. Fournier wrote:
>>> Does anyone know of, or have, any comparisions of the overhead going with
>>> something like pl/perl or pl/php vs using pl/pgsql?
>>
>> Benchmark results will probably depend on the type of processing
>> you're doing.  I'd expect PL/pgSQL to be faster at database operations
>> like looping through query results, and other languages to be faster
>> at non-database operations like text munging and number crunching,
>> depending on the particular language's strengths.
>>
>> [Does quick test.]
>>
>> Whale oil beef hooked.  PL/pgSQL just outran PL/Perl when I expected
>> the latter to win.  Hang on, let me play with it until it comes back
>> with the results I want....
> 
> 'k, let's repharase the questions :)
> 
> Overall, I'd expect pl/pgsql to have less overhead, since its "built into" 
> the server ... in the case of something like pl/php or pl/perl, assuming 
> that I don't use any external modules, is it just as 'built in', or am I 
> effectively calling an external interpreter each time I run that function?
> 
> For instance, if there wasn't something like to_char() (thanks for 
> pointing that one out), then i could write a simple pl/perl function that 
> 'simulated it', but itself did no db queries just a simple:
> 
> RETURN sprintf("%04d", intval);
> 
> Don't know if that made much more sense ... ?
> 
> 
> ----
> Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
> Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
> 
>                http://www.postgresql.org/docs/faq


-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #