[GENERAL] 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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] 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: [EMAIL PROTECTED] 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
Re: [GENERAL] Invocation overhead for procedural languages
2008/8/6 Giorgio Valoti [EMAIL PROTECTED]: 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,1) g(i); sum --- 1 (1 row) Time: 588,649 ms postgres=# select sum(testpg(i)) from generate_series(1,1) g(i); sum --- 1 (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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Invocation overhead for procedural languages
On 06/ago/08, at 16:04, Pavel Stehule wrote: 2008/8/6 Giorgio Valoti [EMAIL PROTECTED]: 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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Invocation overhead for procedural languages
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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Invocation overhead for procedural languages
2008/8/6 Giorgio Valoti [EMAIL PROTECTED]: On 06/ago/08, at 16:04, Pavel Stehule wrote: 2008/8/6 Giorgio Valoti [EMAIL PROTECTED]: 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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
