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
Comments
Commented by: @hvlad Do you speak about tracing of system (internal) queries ? Note, system tables are already present at run-time statistics. |
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 ;) |
Commented by: @hvlad >> it will be very hard to read BLR code instead of SQL one ;) 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 ? |
Commented by: @abzalov I think this will be enough, unless of course the following points confuse: |
Commented by: @hvlad Please, read more careful - above i said about ability to see runtime stats at PREPARE_STATEMENT event. |
Commented by: @abzalov >>Please, read more careful - above i said about ability to see runtime stats at PREPARE_STATEMENT event. 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. |
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.
The text was updated successfully, but these errors were encountered: