Re: Invocation overhead for procedural languages - Mailing list pgsql-general

From Pavel Stehule
Subject Re: Invocation overhead for procedural languages
Date
Msg-id 162867790808062157s6bb1a02dk38c1b3c96187c76@mail.gmail.com
Whole thread Raw
In response to Re: Invocation overhead for procedural languages  (Giorgio Valoti <giorgio_v@mac.com>)
List 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 by date:

Previous
From: "Merlin Moncure"
Date:
Subject: Re: bytea encode performance issues
Next
From: Sim Zacks
Date:
Subject: Re: bytea encode performance issues