From: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | "Giorgio Valoti" <giorgio_v(at)mac(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Invocation overhead for procedural languages |
Date: | 2008-08-07 04:57:52 |
Message-ID: | 162867790808062157s6bb1a02dk38c1b3c96187c76@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
2008/8/6 Giorgio Valoti <giorgio_v(at)mac(dot)com>:
>
> On 06/ago/08, at 16:04, Pavel Stehule wrote:
>
>> 2008/8/6 Giorgio Valoti <giorgio_v(at)mac(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
From | Date | Subject | |
---|---|---|---|
Next Message | Sim Zacks | 2008-08-07 05:16:20 | Re: bytea encode performance issues |
Previous Message | Merlin Moncure | 2008-08-07 04:53:31 | Re: bytea encode performance issues |