Issue Details (XML | Word | Printable)

Key: CORE-6020
Type: Improvement Improvement
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Rashid Abzalov
Votes: 0
Watchers: 4
Operations

If you were logged in you would be able to see more operations.
Firebird Core

Adding the ability to trace (using fbtrace) server access to system tables

Created: 01/Mar/19 06:00 PM   Updated: 05/Mar/19 01:18 PM
Component/s: Engine, TRACEMGR
Affects Version/s: 4.0 Beta 1
Fix Version/s: None

QA Status: No test


 Description  « Hide
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, CORE-5612.

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.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Vlad Khorsun added a comment - 01/Mar/19 06:12 PM
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.

Rashid Abzalov added a comment - 01/Mar/19 06:31 PM
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.

Vlad Khorsun added a comment - 03/Mar/19 10:29 PM
>> 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 ?

Rashid Abzalov added a comment - 04/Mar/19 10:53 AM
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)

Vlad Khorsun added a comment - 04/Mar/19 01:56 PM - edited
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.

Rashid Abzalov added a comment - 05/Mar/19 01:18 PM
>>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.