Re: overhead of plpgsql functions over simple select - Mailing list pgsql-general

From Pavel Stehule
Subject Re: overhead of plpgsql functions over simple select
Date
Msg-id 162867790810232203j696e1b78gaa55158f94fdbef7@mail.gmail.com
Whole thread Raw
In response to Re: overhead of plpgsql functions over simple select  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: overhead of plpgsql functions over simple select  (Ivan Sergio Borgonovo <mail@webthatworks.it>)
List pgsql-general
2008/10/24 Tom Lane <tgl@sss.pgh.pa.us>:
> "Pavel Stehule" <pavel.stehule@gmail.com> writes:
>> postgres=# create function simplefce(a int, b int) returns int as
>> $$select $1 + $2$$ language sql immutable strict;
>> CREATE FUNCTION
>> postgres=# create function simplefce1(a int, b int) returns int as
>> $$begin return a+b; end;$$ language plpgsql immutable strict;
>> CREATE FUNCTION
>
> That's a pretty unfair comparison, because that SQL function is simple
> enough to be inlined.  The place to use plpgsql is when you need some
> procedural logic; at which point a SQL function simply fails to provide
> the required functionality.
>

Yes, this test is maximal unfair to plpgsql - it's too simply
function. But it was original question. What is overhead plpgsql call
on simple functions? On every little bit complicated functions
overhead should be less. And this sample shows sense of using SQL
functions.

regards
Pavel Stehule

>                        regards, tom lane
>

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: overhead of plpgsql functions over simple select
Next
From: Ivan Sergio Borgonovo
Date:
Subject: Re: overhead of plpgsql functions over simple select