Re: proposal: additional error fields

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: proposal: additional error fields
Дата
Msg-id CAFj8pRAGgRg_qvzPAg9ZB4r-j8rXPu33MDuk7Z9FyPKssXVYyQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: additional error fields  (Robert Haas <robertmhaas@gmail.com>)
Список 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 voidLANGUAGE 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Christopher Browne
Дата:
Сообщение: Re: extending relations more efficiently
Следующее
От: Tom Lane
Дата:
Сообщение: Re: extending relations more efficiently