kfaraz commented on code in PR #18569:
URL: https://github.com/apache/druid/pull/18569#discussion_r2379802655


##########
sql/src/main/java/org/apache/druid/sql/http/SqlResource.java:
##########
@@ -97,7 +98,8 @@ public SqlResource(
       final SqlEngineRegistry sqlEngineRegistry,
       final SqlResourceQueryResultPusherFactory resultPusherFactory,
       final DefaultQueryConfig defaultQueryConfig,
-      final ServerConfig serverConfig
+      final ServerConfig serverConfig,
+      final QueryCountStatsProvider counter

Review Comment:
   > An alternative might be to keep a single class/instance, but introduce 1 
layer of indirection to increment/fetch the metrics. This could support future 
combinations of (engine, queryFormat) where entries might look like (native, 
native) or (native, SQL) or (msq, SQL), etc. This way you don't get an 
explosion of unique metric names and/or annotated instances and that 
cardinality is instead pushed into the dimensions under a unified metric.
   
   Yes, it would indeed be nice to accept some kind of `QueryType` in all the 
methods of `QueryCountStatsProvider`.
   
   e.g
   
   ```java
   void incrementSuccessful(QueryType type);
   int getSuccessfulQueryCount(QueryType type);
   
   enum QueryType {NATIVE_JSON, NATIVE_SQL, MSQ, DART}
   ```
   
   The query type will be emitted as a dimension.
   
   But this will require more work as you would need to change the signature of 
`QueryCountStatsProvider` methods
   and pass the query type down to the relevant classes like 
`QueryResultPusher`, etc.
   
   If you feel like making that change, that would work for me too.
   
   Multiple bindings achieves the same result for now (since we are only 
emitting SQL and native query metrics) but with less code change.



-- 
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]

Reply via email to