You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 11, 2018. It is now read-only.
In our case, a query that is OK would shadow a query that causes slowness.
I might be wrong, but if so, I can't explain otherwise why we would not see both queries.
The text was updated successfully, but these errors were encountered:
Thanks for reaching out regarding this issue. I believe you're right and that this is a limitation in the current implementation. We have some different ideas about to better bring to light the slow traces that can get shadowed. I'll leave this open so you can track our progress.
Perhaps results displayed in this way are not super fancy, but true performance report on multiple (but different) queries hitting same table is shown. Queries which are identical should be still grouped together, since they have same hash signature:
We were hunting down a slow endpoint and found this.
If you have two queries hitting the same table inside one call, only one query will report.
Looking at the way
extract_signature()
works, this theory sounds valid:https://github.com/opbeat/opbeat_python/blob/master/opbeat/instrumentation/packages/dbapi2.py#L125
In our case, a query that is OK would shadow a query that causes slowness.
I might be wrong, but if so, I can't explain otherwise why we would not see both queries.
The text was updated successfully, but these errors were encountered: