shauryachats commented on code in PR #17170:
URL: https://github.com/apache/pinot/pull/17170#discussion_r2535793626
##########
pinot-query-runtime/src/main/java/org/apache/pinot/query/runtime/timeseries/TimeSeriesExchangeReceiveOperator.java:
##########
@@ -146,13 +168,37 @@ private TimeSeriesBlock getNextBlockWithAggregation()
timeSeriesList.add(entry.getValue().build());
seriesMap.put(seriesHash, timeSeriesList);
}
- return new TimeSeriesBlock(timeBuckets, seriesMap);
+ return new TimeSeriesBlock(timeBuckets, seriesMap, aggregatedStats);
+ }
+
+ /**
+ * TODO: Consider consolidating stats merging logic with
+ * {@link org.apache.pinot.core.query.reduce.ExecutionStatsAggregator}
+ **/
+ private void mergeStats(Map<String, String> aggregatedStats, Map<String,
String> metadata) {
+ for (DataTable.MetadataKey statKey : ADDITIVE_STATS_KEYS) {
+ String key = statKey.getName();
+ String existingValue = aggregatedStats.get(key);
+ String newValue = metadata.get(key);
+ if (newValue != null) {
+ try {
+ long newLong = Long.parseLong(newValue);
+ long existingLong = existingValue != null ?
Long.parseLong(existingValue) : 0L;
+ aggregatedStats.put(key, Long.toString(existingLong + newLong));
Review Comment:
I understand the intent behind prefixing, though I would hesitate to fully
support that approach, as it introduces additional logic in the construction of
the metadata key. Since the stats metadata keys are centrally defined in
DataTable, adding a “STATS_” prefix to each key could add unnecessary
complexity in handling.
That said, if metadata key collision is a concern, we could consider an
alternative approach - passing the stats metadata in a separate map object from
the servers to the broker. This would effectively isolate stats metadata from
non-stats metadata without adding extra handling logic. This can be achieved in
the next PR when more stats are going to be added.
--
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]
