Re: proposal: additional error fields

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: additional error fields
Date: 2012-05-01 17:15:11
Message-ID: CAFj8pRAGgRg_qvzPAg9ZB4r-j8rXPu33MDuk7Z9FyPKssXVYyQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> Yeah.  I also noticed in my benchmarking that sprintf() seemed to be
> very slow, to the point where I wondered whether we ought to have our
> own minimal version of sprintf() just for error strings.
>
> Another idea would be to pass a flag indicating whether the context
> that's going to receive the error cares about the additional flags.
> If not, we can skip generating the information.  Not sure how much
> that helps, but maybe...
>

complex solution can take time that we can get by sprintf elimination.

some special flags for block can be solution, that can change a behave
of err* functions. Usually we need only SQLSTATE and this can be
minimized.

maybe pl option

create or replace function foo()
returns .. as $$
#option light_exception
begin
...

in this case, only SQLSTATE should be valid. A implementation should
not be hard - but we really need it?

there is oprofile report for bad case:

CREATE OR REPLACE FUNCTION public.fx()
RETURNS void
LANGUAGE plpgsql
AS $function$
declare a int = 0; begin
for i in 1..100000
loop
begin
perform 1/ (a - (i % 1));
exception when others then
/* do nothing */
end;
end loop;
end;
$function$

5871 10.2975 postgres AllocSetAlloc
4472 7.8437 postgres MemoryContextAllocZeroAligned
2570 4.5077 postgres MemoryContextAlloc
2031 3.5623 postgres AllocSetFree
1940 3.4027 postgres SearchCatCache
1906 3.3430 postgres expand_fmt_string.clone.0
1535 2.6923 postgres copyObject
1241 2.1767 postgres fmgr_info_cxt_security
1058 1.8557 postgres MemoryContextCreate
1057 1.8539 postgres ExecInitExpr
1050 1.8417 postgres simplify_function
968 1.6978 postgres pfree
965 1.6926 postgres check_stack_depth
812 1.4242 postgres _copyList.clone.20
801 1.4049 postgres hash_seq_search
777 1.3628 postgres eval_const_expressions_mutator
662 1.1611 postgres expression_tree_mutator
591 1.0366 postgres expression_tree_walker

and good case

postgres=# create or replace function fx()
returns void as $$
declare a int = 1; begin
for i in 1..100000
loop
begin
perform 1/ (a - (i % 1));
exception when others then
/* do nothing */
end;
end loop;
end;
$$ language plpgsql;

7916 10.1067 postgres AllocSetAlloc
5956 7.6043 postgres MemoryContextAllocZeroAligned
3339 4.2631 postgres MemoryContextAlloc
2581 3.2953 postgres SearchCatCache
2348 2.9978 postgres copyObject
2176 2.7782 postgres AllocSetFree
1643 2.0977 postgres MemoryContextCreate
1488 1.8998 postgres ExecInitExpr
1438 1.8360 postgres grouping_planner
1285 1.6406 postgres check_stack_depth
1224 1.5627 postgres fmgr_info_cxt_security
1094 1.3968 postgres pfree
1044 1.3329 postgres _copyList.clone.20
1030 1.3151 postgres eval_const_expressions_mutator
939 1.1989 postgres expression_tree_walker
938 1.1976 postgres simplify_function
889 1.1350 postgres AllocSetDelete
836 1.0674 postgres subquery_planner
834 1.0648 postgres expression_tree_mutator

I don't see a errmsg or errdetail there - the most expensive is
expand_fmt_string with 3%

Regards

Pavel

> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-05-01 17:19:48 Re: extending relations more efficiently
Previous Message Christopher Browne 2012-05-01 17:12:55 Re: extending relations more efficiently