Re: Invocation overhead for procedural languages

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
>

In response to

Browse pgsql-general by date

  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