Akshat-Jain commented on code in PR #17038:
URL: https://github.com/apache/druid/pull/17038#discussion_r1758697749
##########
extensions-core/multi-stage-query/src/main/java/org/apache/druid/msq/querykit/WindowOperatorQueryFrameProcessor.java:
##########
@@ -213,7 +213,8 @@ Current approach with R&C and operators materialize a
single R&C for processing.
Most of the window operations like SUM(), RANK(), RANGE() etc. can be
made with 2 passes of the data. We might think to reimplement them in the MSQ
way so that we do not have to materialize so much data.
*/
- if (partitionColumnNames.isEmpty()) {
+ // todo: need to cleanup unused code and comments
+ if (true) {
Review Comment:
@kgyrtkirk Which layer should the `maxRowsMaterialized` check be enforced
now?
With the current PR changes, most tests in
`WindowOperatorQueryFrameProcessorTest` fail because we are passing the entire
MSQ partition to the list of operators.
Do we need to move `maxRowsMaterialized` check to the
`GlueingPartitioningOperator` layer? If yes, we'd need to fetch the
`maxRowsMaterialized` from query context and use it while creating
`GlueingPartitioningOperator` in the Windowing.java layer?
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]
