Skip to content

WindowOperatorQueryFrameProcessor: Avoid unnecessary re-runs of runIncrementally() #17211

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
cryptoe merged 1 commit into from
Oct 3, 2024
Merged

WindowOperatorQueryFrameProcessor: Avoid unnecessary re-runs of runIncrementally() #17211

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 8 additions & 6 deletions ...-query/src/main/java/org/apache/druid/msq/querykit/WindowOperatorQueryFrameProcessor.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -256,17 +256,19 @@ Most of the window operations like SUM(), RANK(), RANGE() etc. can be made with
} else if (comparePartitionKeys(outputRow, currentRow, partitionColumnNames)) {
// Add current row to the same batch of rows for processing.
rowsToProcess.add(currentRow);
if (rowsToProcess.size() > maxRowsMaterialized) {
// We don't want to materialize more than maxRowsMaterialized rows at any point in time, so process the pending batch.
processRowsUpToLastPartition();
}
ensureMaxRowsInAWindowConstraint(rowsToProcess.size());
} else {
lastPartitionIndex = rowsToProcess.size() - 1;
outputRow = currentRow.copy();
Copy link
Copy Markdown
Member

@kgyrtkirk kgyrtkirk Oct 2, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is odd; outputRow holds a direct reference to currentRow at line 254; but here its being copy-ed; I think they both should be a copy or neither of them...

but again....this will be removed so no big deal

return ReturnOrAwait.runAgain();
Copy link
Copy Markdown
Member

@kgyrtkirk kgyrtkirk Oct 2, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this return was insane... no wonder it have lead to performance degradation...

Copy link
Copy Markdown
Contributor Author

@Akshat-Jain Akshat-Jain Oct 2, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah.. 😅

rowsToProcess.add(currentRow);
}
frameCursor.advance();

if (rowsToProcess.size() > maxRowsMaterialized) {
// We don't want to materialize more than maxRowsMaterialized rows at any point in time, so process the pending batch.
processRowsUpToLastPartition();
ensureMaxRowsInAWindowConstraint(rowsToProcess.size());
return ReturnOrAwait.runAgain();
}
Comment on lines +266 to +271
Copy link
Copy Markdown
Member

@kgyrtkirk kgyrtkirk Oct 2, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

moving this check outside here - will not necessarily enforce that maxRowsMaterialized is honored - but I guess the input frame is already materialized so we may go up to asymptotically twice in mem usage....we can leave it as is for now as this will be improved later

}
return ReturnOrAwait.runAgain();
}
Expand Down