Re: Error handling in plperl and pltcl

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Error handling in plperl and pltcl
Date: 2004-11-20 01:07:05
Message-ID: 447.1100912825@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Tom Lane wrote:
>> This will slow down the PL SPI call operations in both languages, but
>> AFAICS it's the only way to provide error handling semantics that aren't
>> too broken for words.

> Can you estimate the extent of the slowdown?

Without actually doing the work, the closest comparison I can make is
between plpgsql functions with and without exception blocks. I tried

create or replace function foo(int) returns int as '
declare x int;
begin
select into x unique1 from tenk1 where unique2 = $1;
return x;
end' language plpgsql;

create or replace function foo(int) returns int as '
declare x int;
begin
begin
select into x unique1 from tenk1 where unique2 = $1;
exception
when others then null;
end;
return x;
end' language plpgsql;

and used
explain analyze select foo(unique2) from tenk1;
to execute each one 10000 times without too much overhead.
I get about 6900 vs 12800 msec, so for a simple pre-planned query
it's not quite a 50% overhead. This is probably about the worst
case you'd see in practice --- unlike plpgsql, plperl and pltcl
functions wouldn't be calling the SQL engine to do simple arithmetic,
so they're not going to have SPI calls that do much less work than
this example does.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Barry Lind 2004-11-20 01:40:04 Re: [JDBC] Strange server error with current 8.0beta driver
Previous Message Tom Lane 2004-11-20 00:54:41 Re: Error handling in plperl and pltcl