Re: simple functions, huge overhead, no cache

2010/7/12 Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>:
> On 11/07/2010 5:46 AM, Pavel Stehule wrote:
>
>> any using a non simple expression is very slow - so there can be some
>> a warning when people use it. Sometimes people don't know (me too),
>> when use expensive expression
>>
>> for example
>>
>> rowvar := (10,20)
>>
>> it isn't simple - I am not sure, if it is true still.
>
> Rather than warning whenever the SPI is invoked from PL/PgSQL, perhaps this
> would be a task better suited for inclusion in a profiler feature for the
> PL/PgSQL debugger?
>
> I'm not particularly interested in the notion myself, but I don't think
> warnings about "non-simple" statements would be very helpful. You'd be
> drowned in warnings for statements that were a necessary part of the
> operation of your functions, things for which there was no other way to do
> it.

I think, so it is warnings has more education sense. Because it is
interactive. It simply show - "don't do it". More - it can be done in
validation time - so it hasn't any impact on real speed (I know it is
mas/menos). There are a few basic a plpgsql repeated mistakes - and I
think so some of these can be catched via warnings.

see http://okbob.blogspot.com/2010/04/frequent-mistakes-in-plpgsql-design.html

I am thinking so plpgsql has a full functionality - there are not too
much issues - so next direction of developing can be a smarted
validation and more verbose diagnostics (now diagnostics (syntax
error, runtime error) are pretty well). There a issue with assign
statement with quite bin-text/text-bin transformation -

declare a int;
begin
a := 4;

because "4" is a numeric and "a" is integer, then in runtime time it
does numeric/string and string to integer transformations. And it is
relative innocent statement. Some like this are traps on beginners.

>
> It seems like a profiler, which is designed to filter and organize the
> collected data, and which can be attached only to specific functions that
> you want to know about, might be a better job. As there's already a PL/PgSQL
> debugger, some of the infrastructure required is already present.

there is a pl/pgsql profiler too. but profiler isn't "interactive".
More - profiler/debugger are third-party software - so it isn't
availlable everywhere.

>
> Meh, personally I'll stick to the good old profiling methods "is it fast
> enough", "\timing", and "explain analyze".

Both tools has a sense - we have a warnings in gcc and we have a profilers too.

Regards

Pavel Stehule

>
> --
> Craig Ringer
>