LakshSingla commented on code in PR #16854:
URL: https://github.com/apache/druid/pull/16854#discussion_r1722820853
##########
extensions-core/multi-stage-query/src/main/java/org/apache/druid/msq/querykit/WindowOperatorQueryKit.java:
##########
@@ -360,4 +354,36 @@ private QueryDefinitionBuilder
makeQueryDefinitionBuilder(String queryId, DataSo
}
return queryDefBuilder;
}
+
+ /**
+ * Computes the ClusterBy for the final window stage which may or may not
have the partition boosted column,
+ * depending on the {@code segmentGranularity} parameter passed. We don't
have to take the CLUSTERED BY
+ * columns into account, as they are handled as {@link
org.apache.druid.query.scan.ScanQuery#orderBys}.
+ */
+ private static ClusterBy computeClusterByForFinalWindowStage(Granularity
segmentGranularity)
Review Comment:
What's the harm?
edit: Partition boosting provides a way to disambiguate between the rows
having the same keys. The segment granularity doesn't play into the decision
here. There is an argument that it's required more for when granularity = ALL,
however since we have added the boosting anyway in the query kit, it makes
little sense to conditionally gate it for ALL granularity. Thoughts?
--
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]
