Re: pl/* overhead ... - Mailing list pgsql-sql

From Marc G. Fournier
Subject Re: pl/* overhead ...
Date
Msg-id 20051026064246.Q993@ganymede.hub.org
Whole thread Raw
In response to Re: pl/* overhead ...  (Michael Fuhr <mike@fuhr.org>)
Responses Re: pl/* overhead ...
List pgsql-sql
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


pgsql-sql by date:

Previous
From: Stef
Date:
Subject: Re: converting epoch to timestamp
Next
From: "Christian Paul B. Cosinas"
Date:
Subject: SETOF RECORD RETURN VALUE