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
Currently instumentation-pg tries to infer query type (SELECT/INSERT/UPDATE) from the sql text. This logic is not very robust as you can see on the screenshot. It just takes the first word of the query and adds it to span name. Even when operation is deduced successfully I personally do not find it very meaningful to have it in span name. When there are few queries it can provide some benefit by speeding up the navigation I find that most often I need to check each span with its attributes to find the one I am interested in.
So the proposal is to simplify the logic and generate the same span name for all the queries, like pg.query or something similar. With this instrumentation being one of the most used in our setup it may also provide the benefit of reducing allocations
So the proposal is to simplify the logic and generate the same span name for all the queries
I don't think that would be helpful, since this would now allow any type of filtering/search if they're all the same.
We can maybe use the beginning of the query (with a limit of amount of strings), that can be a little more helpful.
Another option would allow some sort of tag for queries, so users can add labels to the queries they care the most, making it easier to find them later on.
Currently
instumentation-pg
tries to infer query type (SELECT/INSERT/UPDATE) from the sql text. This logic is not very robust as you can see on the screenshot. It just takes the first word of the query and adds it to span name. Even when operation is deduced successfully I personally do not find it very meaningful to have it in span name. When there are few queries it can provide some benefit by speeding up the navigation I find that most often I need to check each span with its attributes to find the one I am interested in.So the proposal is to simplify the logic and generate the same span name for all the queries, like
pg.query
or something similar. With this instrumentation being one of the most used in our setup it may also provide the benefit of reducing allocationsFor reference
#2029 (comment)
The text was updated successfully, but these errors were encountered: