Re: Performance costs of various PL languages

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: Performance costs of various PL languages
Дата
Msg-id CAFj8pRB-D6mmLQeffncWo-QrtDLW_ynwhQjnZsSzNfb0t_gQLQ@mail.gmail.com
обсуждение исходный текст
Ответ на Performance costs of various PL languages  ("Carlo Stonebanks" <stonec.register@sympatico.ca>)
Ответы Re: Performance costs of various PL languages
Список pgsql-performance
Hello

2011/12/27 Carlo Stonebanks <stonec.register@sympatico.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@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance

В списке pgsql-performance по дате отправления:

Предыдущее
От: "Carlo Stonebanks"
Дата:
Сообщение: Performance costs of various PL languages
Следующее
От: Ondrej Ivanič
Дата:
Сообщение: Re: Subquery flattening causing sequential scan