rohangarg commented on code in PR #12923:
URL: https://github.com/apache/druid/pull/12923#discussion_r950144842
##########
sql/src/main/java/org/apache/druid/sql/SqlExecutionReporter.java:
##########
@@ -105,9 +111,16 @@ public void emit()
if (bytesWritten >= 0) {
emitter.emit(metricBuilder.build("sqlQuery/bytes", bytesWritten));
}
+ if (planningTimeNanos >= 0) {
+ emitter.emit(metricBuilder.build(
+ "sqlQuery/planningTimeMs",
+ TimeUnit.NANOSECONDS.toMillis(planningTimeNanos)
+ ));
+ }
final Map<String, Object> statsMap = new LinkedHashMap<>();
statsMap.put("sqlQuery/time",
TimeUnit.NANOSECONDS.toMillis(queryTimeNs));
+ statsMap.put("sqlQuery/planningTimeMs",
TimeUnit.NANOSECONDS.toMillis(planningTimeNanos));
Review Comment:
Yes, I didn't mean to say that we'd update the current metric. Rather that
incase anyone tries to use it for a new metric or derive a metric using the
planningTime, they would have the value with highest accuracy.
In my local tests with `SELECT 1` query, even after multiple quick
invocations the lowest planning time I saw was `4ms`. The lowest `query/time`
observed was `6ms`. Have you seen < millisecond scale planning in production
clusters maybe - which my local test would be missing?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
