Re: overhead of plpgsql functions over simple select

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
>

In response to

Responses

Browse pgsql-general by date

  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