Lists: | pgsql-general |
---|
From: | Giorgio Valoti <giorgio_v(at)mac(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Invocation overhead for procedural languages |
Date: | 2008-08-06 12:44:16 |
Message-ID: | 4E3668CB-2E0A-45F9-B20F-22657DFEEEA6@mac.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-general |
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
From: | Martin Gainty <mgainty(at)hotmail(dot)com> |
---|---|
To: | Giorgio Valoti <giorgio_v(at)mac(dot)com>, <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Invocation overhead for procedural languages |
Date: | 2008-08-06 13:58:08 |
Message-ID: | BLU142-W12DB464E08A45E5C98839AAE7A0@phx.gbl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-general |
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(at)postgresql(dot)org
> From: giorgio_v(at)mac(dot)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(at)postgresql(dot)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
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-06 14:04:56 |
Message-ID: | 162867790808060704m643ed8c2i7dcb1e0bcd114128@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-general |
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.
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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
From: | Giorgio Valoti <giorgio_v(at)mac(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Invocation overhead for procedural languages |
Date: | 2008-08-06 18:48:09 |
Message-ID: | 4E198A05-E6C4-4A1E-9B51-70E39F570844@mac.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-general |
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?
>
>
> […]
>
> but you can load perl after server start - look on preload_libraries
> section in postgresql.conf
Nice to know.
Thank you Pavel
--
Giorgio Valoti
From: | Ragnar <gnari(at)hive(dot)is> |
---|---|
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-06 22:26:56 |
Message-ID: | 1218061616.10575.5.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-general |
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
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 |
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
>