Details
-
Improvement
-
Resolution: Duplicate
-
Major
-
5.0.0
-
None
Description
I was working on a simple query to find the top 5 queries. As a novice user, this should be as simple as: SELECT * FROM completed_requests WHERE ElapsedTime > 5000; (or whatever the order of magnitude should be)
However, I needed the experts to explain to me that ElapsedTime is actually including the units and so is not integer comparable. The resulting query is:
SELECT * FROM system:completed_requests WHERE STR_TO_DURATION(ElapsedTime) > STR_TO_DURATION("5s") ORDER BY STR_TO_DURATION(ElapsedTime)
I do understand that there is value in human readable fields, and certainly now we can't make any change that breaks existing applications that are relying on this.
So, two suggestions I'd like us to consider:
- Slightly modify the existing fields to use "00:00:05" as a SQL-standard duration. This should still allow STR_TO_DURATION to work, but make it much easier to do something like ElapsedTIme > 00:00:05
- Add secondary fields like ElapsedTime_nano and have it be the integer value. This won't break any existing applications, but would give users a much easier-to-read value going forward.
Hopefully you agree (or can help me understand why it's not a good idea) and we can apply one of these across the board to our duration fields.
p.s. got some similar feedback from one of our customers. I quote:
"
Localhost:8093/admin/vitals
Why oh why are you using human readable time metrics,
"request_time.mean":"170.870877ms",
"request_time.median":"733.364µs",
"request_time.80percentile":"21.85926ms",
"request_time.95percentile":"1.274152266s",
"request_time.99percentile":"1.588775188s",
I can’t imagine many people will be hitting this endpoint and reading it themselves, more likely it will be read by some agent and displayed on a dashboard, it’s going to be a real issue converting them, what wrong with seconds as an integer.