Open firebird-automations opened 5 years ago
firebird-automations
commented
5 years ago Commented by: @hvlad
Do you speak about tracing of system (internal) queries ? If yes, it will be very hard to read BLR code instead of SQL one ;)
Note, system tables are already present at run-time statistics.
firebird-automations
commented
5 years ago Commented by: @abzalov
Yes, I meant the tracing of the system queries.
>>it will be very hard to read BLR code instead of SQL one ;) Hard to read for the user? If from this information it will be possible to understand to which table the request is made, with what condition, which indices were used and how much time is spent on it, then this will be enough.
firebird-automations
commented
5 years ago Commented by: @hvlad
>> it will be very hard to read BLR code instead of SQL one ;) > Hard to read for the user?
Sure.
> If from this information it will be possible to understand to which table the request is made, with what condition, which indices were used and how much time is spent on it, then this will be enough.
What if you could see it in runtime stats at PREPARE_STATEMENT event ?
firebird-automations
commented
5 years ago Commented by: @abzalov
I think this will be enough, unless of course the following points confuse: - necessity to watch tracing in different places - user requests in fbtrace, and system requests in the statistics of the run time stats (for us this is not a problem) - if these statistics are always collected and cannot be turned on/off as needed (as is done in fbtrace), then overhead can slow down the execution of requests (perhaps I am mistaken)
firebird-automations
commented
5 years ago Commented by: @hvlad
Please, read more careful - above i said about ability to see runtime stats at PREPARE_STATEMENT event. It is about trace of course, and runitme stats could be reported in the way as for EXECUTE_STATEMENT_FINISH event. Stats will be collected if interesting trace session(s) present, of course - the same way as for other events with stats reported.
firebird-automations
commented
5 years ago Commented by: @abzalov
>>Please, read more careful - above i said about ability to see runtime stats at PREPARE_STATEMENT event. Now I understand what you mean.
Yes, the information shown in the EXECUTE_STATEMENT_FINISH event appears to be sufficient.
Similar information for system requests would be shown in any event (state) of original user request. However, as far as I know, all "work" for DDL statements is done at the COMMIT of transaction. If this is true, then execution statistics will not yet be available during the logging the PREPARE_STATEMENT event of original user request.
Submitted by: @abzalov
Adding the ability to trace (using fbtrace) server access to system tables. Now the use of system tables are not visible when tracing.
This feature will allow to "see" for what the time is spent in some ambiguous situations, such as, for example, CORE5612.
Also, this opportunity can be used not only by those who understand the source code of Firebird, but also by others. Now, without profiling skills, this cannot be done without contacting the Firebird developers. But it seems to me not rational to spend their time and professional skills on such issues, because less experienced users would have coped with it.
On the other hand, the quality of the description of issues would be much better, because they would be able to independently gather the necessary information (with understanding of what is happening) before creating the incident. And in some cases, they would not even begin to create an issue, since would understand the problem or found the workaround yourself.