Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding the ability to trace (using fbtrace) server access to system tables [CORE6020] #6270

Open
firebird-automations opened this issue Mar 1, 2019 · 6 comments

Comments

@firebird-automations
Copy link
Collaborator

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.

@firebird-automations
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant