Re: Performance costs of various PL languages

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Carlo Stonebanks <stonec(dot)register(at)sympatico(dot)ca>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Performance costs of various PL languages
Date: 2011-12-27 22:20:11
Message-ID: CAFj8pRB-D6mmLQeffncWo-QrtDLW_ynwhQjnZsSzNfb0t_gQLQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Hello

2011/12/27 Carlo Stonebanks <stonec(dot)register(at)sympatico(dot)ca>:
> We are currently using pltclu as our PL of choice AFTER plpgSql.
>
> I'd like to know if anyone can comment on the performance costs of the
> various PL languages BESIDES C. For example, does pltclu instantiate faster
> than pltcl (presumably because it uses a shared interpreter?) Is Perl more
> lightweight?
>
> I know that everything depends on context - what you are doing with it, e.g.
> choose Tcl for string handling vs. Perl for number crunching - but for those
> who know about this, is there a clear performance advantage for any of the
> various PL languages - and if so, is it a difference so big to be worth
> switching?
>
> I ask this because I had expected to see pl/pgsql as a clear winner in terms
> of performance over pltclu, but my initial test showed the opposite. I know
> this may be an apples vs oranges problem and I will test further, but if
> anyone has any advice or insight, I would appreciate it so I can tailor my
> tests accordingly.
>

A performance strongly depends on use case.

PL/pgSQL has fast start but any expression is evaluated as simple SQL
expression - and some repeated operation should be very expensive -
array update, string update. PL/pgSQL is best as SQL glue. Positive to
performance is type compatibility between plpgsql and Postgres.
Interpret plpgsql is very simply - there are +/- zero optimizations -
plpgsql code should be minimalistic, but when you don't do some really
wrong, then a speed is comparable with PHP.

http://www.pgsql.cz/index.php/PL/pgSQL_%28en%29#Inappropriate_use_of_the_PL.2FpgSQL_language

PL/Perl has slower start - but string or array operations are very
fast. Perl has own expression evaluator - faster than expression
evaluation in plpgsql. On second hand - any input must be transformed
from postgres format to perl format and any result must be transformed
too. Perl and other languages doesn't use data type compatible with
Postgres.

Regards

Pavel Stehule

>
> Thanks,
>
> Carlo
>
>
>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Ondrej Ivanič 2011-12-27 22:21:00 Re: Subquery flattening causing sequential scan
Previous Message Carlo Stonebanks 2011-12-27 21:09:50 Performance costs of various PL languages