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
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 |