amrishlal commented on a change in pull request #6710:
URL: https://github.com/apache/incubator-pinot/pull/6710#discussion_r605993528
##########
File path:
pinot-common/src/main/java/org/apache/pinot/common/utils/DataTable.java
##########
@@ -80,4 +85,85 @@
double[] getDoubleArray(int rowId, int colId);
String[] getStringArray(int rowId, int colId);
+
+ /* The MetadataKey is used in V3, where we present metadata as
Map<MetadataKey, String>
+ * ATTENTION:
+ * - Don't change existing keys.
+ * - Don't remove existing keys.
+ * - Always add new keys to the end.
+ * Otherwise, backward compatibility will be broken.
+ */
+ enum MetadataKey {
+ UNKNOWN("unknown"),
+ TABLE("table"), // NOTE: this key is only used in PrioritySchedulerTest
+ NUM_DOCS_SCANNED("numDocsScanned"),
+ NUM_ENTRIES_SCANNED_IN_FILTER("numEntriesScannedInFilter"),
+ NUM_ENTRIES_SCANNED_POST_FILTER("numEntriesScannedPostFilter"),
+ NUM_SEGMENTS_QUERIED("numSegmentsQueried"),
+ NUM_SEGMENTS_PROCESSED("numSegmentsProcessed"),
+ NUM_SEGMENTS_MATCHED("numSegmentsMatched"),
+ NUM_CONSUMING_SEGMENTS_PROCESSED("numConsumingSegmentsProcessed"),
+ MIN_CONSUMING_FRESHNESS_TIME_MS("minConsumingFreshnessTimeMs"),
+ TOTAL_DOCS("totalDocs"),
+ NUM_GROUPS_LIMIT_REACHED("numGroupsLimitReached"),
+ TIME_USED_MS("timeUsedMs"),
+ TRACE_INFO("traceInfo"),
+ REQUEST_ID("requestId"),
+ NUM_RESIZES("numResizes"),
+ RESIZE_TIME_MS("resizeTimeMs"),
+ THREAD_CPU_TIME_NS("threadCpuTimeNs");
+
+ private static final Map<String, MetadataKey> _nameToEnumKeyMap = new
HashMap<>();
+ // _intValueMetadataKey contains all metadata keys which has value of int
type.
+ private static final Set<MetadataKey> _intValueMetadataKey = ImmutableSet
+ .of(MetadataKey.NUM_SEGMENTS_QUERIED,
MetadataKey.NUM_SEGMENTS_PROCESSED, MetadataKey.NUM_SEGMENTS_MATCHED,
+ MetadataKey.NUM_RESIZES,
MetadataKey.NUM_CONSUMING_SEGMENTS_PROCESSED, MetadataKey.NUM_RESIZES);
+ // _longValueMetadataKey contains all metadata keys which has value of
long type.
Review comment:
Looks good, but wondering if we can use ColumnDataType (which is widely
used already) instead of defining a new enum which more or less means the same
thing? I think the ordinal position of values in ColumnDataType is already
fixed (from serialization, deserialization point of view), but for safety we
can add a comment their saying not to change the ordinal position.
--
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.
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
