Thread: Invocation overhead for procedural languages

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?

Thank you in advance
--
Giorgio Valoti

if you're using apache yes your module's performance is related to how many child processes are spawned by mod_prefork

http://httpd.apache.org/docs/2.2/mod/prefork.html

HTH
Martin
______________________________________________
Disclaimer and confidentiality note
Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission.


> To: pgsql-general@postgresql.org
> From: giorgio_v@mac.com
> Subject: [GENERAL] Invocation overhead for procedural languages
> Date: Wed, 6 Aug 2008 14:44:16 +0200
>
> 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?
>
> Thank you in advance
> --
> 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

---

Get Windows Live and get whatever you need, wherever you are. Start here.

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.

postgres=# create function testpg(a integer) returns integer as
$$begin return 1; end; $$ language plpgsql immutable;
CREATE FUNCTION
postgres=# create function testperl(a integer) returns integer as
$$return 1;$$ language plperl;
CREATE FUNCTION

postgres=# select sum(testperl(i)) from generate_series(1,10000) g(i);
  sum
-------
 10000
(1 row)

Time: 588,649 ms
postgres=# select sum(testpg(i)) from generate_series(1,10000) g(i);
  sum
-------
 10000
(1 row)

Time: 51,214 ms

so in this trivial function is plpgql faster then perl, that is fata morgana :).

first start is diferent:
postgres=# select testpg(1);
 testpg
--------
      1
(1 row)

Time: 3,409 ms
postgres=# select testperl(1);
 testperl
----------
        1
(1 row)

Time: 86,199 ms
second is similar
postgres=# select testperl(1);
 testperl
----------
        1
(1 row)

Time: 1,059 ms
postgres=# select testpg(1);
 testpg
--------
      1
(1 row)

Time: 0,955 ms

but you can load perl after server start - look on preload_libraries
section in postgresql.conf

regards
Pavel Stehule

>
> Thank you in advance
> --
> 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
>

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?

>
>
> […]
>
> but you can load perl after server start - look on preload_libraries
> section in postgresql.conf

Nice to know.

Thank you Pavel
--
Giorgio Valoti

On mið, 2008-08-06 at 20:48 +0200, Giorgio Valoti wrote:
> On 06/ago/08, at 16:04, Pavel Stehule wrote:
>
> >
> > it's depend. Start of interpret is only one overhead.
> > Other is date
> > conversions to language compatible types (without C and plpgsql).

> So is plpgsql slower on date conversion than other languages? Just
> curious: why does shared evaluation add some overhead?
>

I am sure he meant "data" conversion , not "date"

gnari

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
>