pg.ddx.io pgsql-sql@postgresql.org mailing list archive
help / color / mirror / Atom feedpl/* overhead ...
4+ messages / 3 participants
[nested] [flat]
* pl/* overhead ...
@ 2005-10-26 03:58 Marc G. Fournier <scrappy@postgresql.org>
0 siblings, 1 reply; 4+ messages in thread
From: Marc G. Fournier @ 2005-10-26 03:58 UTC (permalink / raw)
To: pgsql-sql
Does anyone know of, or have, any comparisions of the overhead going with
something like pl/perl or pl/php vs using pl/pgsql?
Thanks ...
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: pl/* overhead ...
@ 2005-10-26 06:55 Michael Fuhr <mike@fuhr.org>
parent: Marc G. Fournier <scrappy@postgresql.org>
0 siblings, 1 reply; 4+ messages in thread
From: Michael Fuhr @ 2005-10-26 06:55 UTC (permalink / raw)
To: Marc G. Fournier <scrappy@postgresql.org>; +Cc: pgsql-sql
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....
--
Michael Fuhr
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: pl/* overhead ...
@ 2005-10-26 09:48 Marc G. Fournier <scrappy@postgresql.org>
parent: Michael Fuhr <mike@fuhr.org>
0 siblings, 1 reply; 4+ messages in thread
From: Marc G. Fournier @ 2005-10-26 09:48 UTC (permalink / raw)
To: Michael Fuhr <mike@fuhr.org>; +Cc: 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
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: pl/* overhead ...
@ 2005-10-26 14:28 Jan Wieck <JanWieck@Yahoo.com>
parent: Marc G. Fournier <scrappy@postgresql.org>
0 siblings, 0 replies; 4+ messages in thread
From: Jan Wieck @ 2005-10-26 14:28 UTC (permalink / raw)
To: Marc G. Fournier <scrappy@postgresql.org>; +Cc: Michael Fuhr <mike@fuhr.org>; pgsql-sql
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 #
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2005-10-26 14:28 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2005-10-26 03:58 pl/* overhead ... Marc G. Fournier <scrappy@postgresql.org>
2005-10-26 06:55 ` Michael Fuhr <mike@fuhr.org>
2005-10-26 09:48 ` Marc G. Fournier <scrappy@postgresql.org>
2005-10-26 14:28 ` Jan Wieck <JanWieck@Yahoo.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox