Re: Invocation overhead for procedural languages

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: Invocation overhead for procedural languages
Дата
Msg-id 162867790808062157s6bb1a02dk38c1b3c96187c76@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Invocation overhead for procedural languages  (Giorgio Valoti <giorgio_v@mac.com>)
Список pgsql-general
2008/8/6 Giorgio Valoti <giorgio_v@mac.com>:
>
> On 06/ago/08, at 16:04, Pavel Stehule wrote:
>
>> 2008/8/6 Giorgio Valoti <giorgio_v@mac.com>:
>>>
>>> Hi all, I think I've read somewhere in the documentation that the
>>> invocation
>>> of functions written in procedural languages (with the exception of
>>> plpgsql)
>>> incur in performance hit due to the call the language interpreter. Is
>>> that
>>> correct or am I completely off track?
>>
>> it's depend. Start of interpret is only one overhead.
>> Other is date
>> conversions to language compatible types (without C and plpgsql).
>> Only plpgsql share expression evaluation with database, so it's
>> specific overhead only for plpgsql.
>
> So is plpgsql slower on date conversion than other languages? Just curious:
> why does shared evaluation add some overhead?

I am sorry - data conversions. Plpgsql do only necessary conversions,
because values are stored in postgresql compatible binary format.

>
>>
>>
>> […]
>>
>> but you can load perl after server start - look on preload_libraries
>> section in postgresql.conf
>
> Nice to know.
>
> Thank you Pavel
> --
> Giorgio Valoti
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

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

Предыдущее
От: "Merlin Moncure"
Дата:
Сообщение: Re: bytea encode performance issues
Следующее
От: Sim Zacks
Дата:
Сообщение: Re: bytea encode performance issues