From: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Ivan Sergio Borgonovo" <mail(at)webthatworks(dot)it>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: overhead of plpgsql functions over simple select |
Date: | 2008-10-24 05:03:35 |
Message-ID: | 162867790810232203j696e1b78gaa55158f94fdbef7@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
2008/10/24 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Ivan Sergio Borgonovo | 2008-10-24 07:13:40 | Re: overhead of plpgsql functions over simple select |
Previous Message | Tom Lane | 2008-10-24 04:46:22 | Re: overhead of plpgsql functions over simple select |