-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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.
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
ESQL: Copy blocks when expanding #100548
ESQL: Copy blocks when expanding #100548
Conversation
Until we get lovely reference tracking, let's copy the blocks. This fixes the memory tracking around mv_expand, but it requires a copy. For now, that's simple and it works. I expect we won't copy forever. We can likely share the array once we get reference tracking. But for now, let's copy!
Pinging @elastic/es-ql (Team:QL) |
Pinging @elastic/elasticsearch-esql (:Query Languages/ES|QL) |
I'm not sure if we'll need to do this with @luigidellaquila's fix to cut blocks into more than one page on mv_expand, but this works for now. Have a look and decide what to do with it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two smaller comments; but this looks great. Thanks Nik!
boolean success = false; | ||
try { | ||
for (int b = 0; b < result.length; b++) { | ||
result[b] = b == channel ? expandedBlock : page.getBlock(b).filter(duplicateFilter); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we assign the expandedBlock
to the result
array before the loop to ensure that we always release it in case we hit the breaker with b < channel
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
++
$endif$ | ||
} | ||
} | ||
return builder.mvOrdering(mvOrdering()).build(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can assign MvOrdering.DEDUPLICATED_AND_SORTED_ASCENDING
for the expanded block?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah! It shouldn't really matter because it doesn't have duplicated blocks, but that's technically correct!
Until we get lovely reference tracking, let's copy blocks when "expanding" them. For now, that's simple and it works and helps make memory tracking cleaner. I expect we won't copy forever. We can likely share the array once we get reference tracking. But for now, let's copy! Closes elastic#100548
Replaced by #100778. |
Until we get lovely reference tracking, let's copy blocks when "expanding" them. For now, that's simple and it works and helps make memory tracking cleaner. I expect we won't copy forever. We can likely share the array once we get reference tracking. But for now, let's copy! Closes #100548
Until we get lovely reference tracking, let's copy blocks when "expanding" them. For now, that's simple and it works and helps make memory tracking cleaner. I expect we won't copy forever. We can likely share the array once we get reference tracking. But for now, let's copy! Closes elastic#100548
Until we get lovely reference tracking, let's copy blocks when "expanding" them. For now, that's simple and it works and helps make memory tracking cleaner. I expect we won't copy forever. We can likely share the array once we get reference tracking. But for now, let's copy! Closes #100548
Until we get lovely reference tracking, let's copy the blocks. This fixes the memory tracking around mv_expand, but it requires a copy. For now, that's simple and it works. I expect we won't copy forever. We can likely share the array once we get reference tracking. But for now, let's copy!
Closes #100548