contrib/database/sql: customizable resource naming

[mbyio]

I work on a service that has to use complicated and varying WHERE expressions in its queries. There is no way to avoid this because, among other reasons, we have to use IN expressions with a varying number of arguments, and we can not convert the IN expressions into JOINs for performance reasons. This makes the Datadog APM UI harder to use because it results in a very high cardinality of resource names. The docs also indicate there is a hard limit to the allowed cardinality of a resource, and we don't want to lose data.

There are some things you could do automatically to try and group queries. But I think it might be better if you just let users customize it as an option, since there isn't really a way to cover every use case for every database. So, can you provide a hook so we can set our own function that normalizes resource names in queries? (And maybe you could provide a few examples that people can use if it fits their use case.)

Eg. I'd like to be able to write a function that automatically turns a query like this:

SELECT col1, col2, col3
FROM tablea JOIN tableb on tablea.col52 = tableb.col3
WHERE (tablea.col5 in (?, ?, ?, ?) AND tableb.col4 in (?, ?)) AND tablea.col76 = 5 AND tableb.col33 in (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)

into a query like SELECT col1, col2, col3 FROM tablea JOIN tableb ON tablea.col52 = tableb.col3 using a regular expression. Then the original query could be added as a tag so it can still be viewed for debugging.

[gbbr]

Thanks for reporting this. I think this is a great idea and we should definitely consider having something like this. This would indeed reduce cardinality and could make sense as an opt-in feature. Would you ming moving it to the trace-agent repository though? Quantization and obfuscation happens there and that's where this needs to be addressed.

[gbbr]

P.S. It should be good enough to copy/paste the description. I'd be happy to do it for you but I want you to be subscribed and receive updates to the issue.