EQL: Fix early trimming of in-flight data#66493
Conversation
6fc9ba0 to
2e0d465
Compare
Rework trimToLast to take into account an ordinal for last trimming so instead of keeping the last entry in a stage, it keeps the last entry before the given ordinal. This takes care of the case where a dense stage that requires several passes does not discard valid data from a previous sparse stage that go beyond the current stage point.
2e0d465 to
5a63383
Compare
|
Pinging @elastic/es-ql (Team:QL) |
| // and remember the last item from the first | ||
| // initialized stage to be used with until | ||
| // remember the last item found (will be ascending) | ||
| // to trim unneeded until that occur before it |
There was a problem hiding this comment.
| // to trim unneeded until that occur before it | |
| // to trim the ones before it |
|
|
||
| /** | ||
| * Returns the latest element from the group that has its timestamp | ||
| * less than the given argument alongside its position in the list. |
There was a problem hiding this comment.
| * less than the given argument alongside its position in the list. | |
| * less than the given argument's timestamp, alongside its position in the list. |
| /** | ||
| * Returns the latest element from the group that has its timestamp | ||
| * less than the given argument alongside its position in the list. | ||
| * Everything before the element it is removed. The element is kept. |
There was a problem hiding this comment.
| * Everything before the element it is removed. The element is kept. | |
| * Everything before this element is removed. The element is kept. |
There was a problem hiding this comment.
Will pick them up in a separate PR to avoid another build.
| * and adjust insertion positions. | ||
| */ | ||
| void trim(boolean everything) { | ||
| void trim(Ordinal ordinal) { |
There was a problem hiding this comment.
Wondering if @Nullable would be welcome here, as an indicator of null as a branching value?
There was a problem hiding this comment.
I'm not a fan of @Nullable since it doesn't enforce anything nor it is used consistently through-out the code.
matriv
left a comment
There was a problem hiding this comment.
LGTM, Is there any integration test that can be used to validate this fix?
Yes, the correctness test with tail by default. Our smaller tests seems to trigger it but I haven't had time to double check if this is indeed the case. |
Rework trimToLast to take into account an ordinal for last trimming so instead of keeping the last entry in a stage, it keeps the last entry before the given ordinal. This takes care of the case where a dense stage that requires several passes does not discard valid data from a previous sparse stage that go beyond the current stage point. (cherry picked from commit 4f55749)
Rework trimToLast to take into account an ordinal for last trimming so instead of keeping the last entry in a stage, it keeps the last entry before the given ordinal. This takes care of the case where a dense stage that requires several passes does not discard valid data from a previous sparse stage that go beyond the current stage point. (cherry picked from commit 4f55749) (cherry picked from commit 6b61dfe)
Rework trimToLast to take into account an ordinal for last trimming so instead of keeping the last entry in a stage, it keeps the last entry before the given ordinal. This takes care of the case where a dense stage that requires several passes does not discard valid data from a previous sparse stage that go beyond the current stage point. (cherry picked from commit 4f55749) (cherry picked from commit 6b61dfe) (cherry picked from commit cece81b)
|
Backported to 7.x, 7.11 and 7.10 |
Rework trimToLast to take into account an ordinal for last trimming so
instead of keeping the last entry in a stage, it keeps the last entry
before the given ordinal.
This takes care of the case where a dense stage that requires several
passes does not discard valid data from a previous sparse stage that go
beyond the current stage point.