> -----Original Message-----
> From: Thomas Steinmaurer [mailto:t...@iblogmanager.com]
> Sent: Martes, 10 de Julio de 2012 2:47
>
> I and quite a few other Trace API users believe, that a
> traced PSQL call
> is too much of a black-box currently. We already have a trace
> output for
> embedded procedure calls anyway, so why not offer the expected
> EXECUTE_STATEMENT_* trace events for embedded DML calls as
> well? If this
> has too much cost, then make it configurable via an additional trace
> configuration option.
>
> The problem with in-depth debugging/profiling usually is, that this
> needs to happen in a test environment, cause you simply can't
> execute a
> critical SP in a production database that easy. And you usually don't
> have the same conditions in respect to data volume and especially the
> real production load, thus IMHO it would be useful to have at
> least the
> various EXECUTE_STATEMENT_* calls resulting from PSQL tracing with
> real-life statistics, execution plan etc. If technical possible.
I think that making everyone pay the cost of the overhead generated by so
many "hooks" inside the engine is a very bad idea. For me, it would be a
great thing if all tracing and encryption code produces zero CPU usage when
not enabled. This is an ideal world, of course.
At the PSQL level, it would suffice for tracing purposes to have a call,
like
USER_TRACE("<string>");
and you can put whatever you want there. Now, the overhead is explicit. Even
more, if there was a way to say
ALTER PROCEDURE p TRACE ON
ALTER PROCEDURE p TRACE OFF
then the body would be recompiled and when the param is OFF, all USER_TRACE
statements would be ignored by the parser.
C.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
