Invocation overhead for procedural languages

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.
http://www.windowslive.com/default.html?ocid=TXT_TAGLM_WL_Home_082008

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

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.