fix time column seeking for time ordered projections#17711
Merged
clintropolis merged 1 commit intoapache:masterfrom Feb 12, 2025
Merged
fix time column seeking for time ordered projections#17711clintropolis merged 1 commit intoapache:masterfrom
clintropolis merged 1 commit intoapache:masterfrom
Conversation
gianm
approved these changes
Feb 11, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Fixes a bug in time ordered projections resulting from #17397. The changes in that PR resulted in a
QueryableIndexCursorHolderof a projection using aQueryableIndexTimeBoundaryInspectorthat was pointing to the base table __time column instead of the projections time column, which could result in seeking to the incorrect the starting offset when the time column of a projection is transformed due to the code checking the time column against the 'start' timestamp of the base table instead of the projection table.For example, imagine we have a base table which has a first row with a
__timevalue of2025-02-10T00:01:01Zor whatever, and a time ordered projection exists which doesTIME_FLOOR(__time, 'PT1H'), so the first value of the projection time column would be2025-02-10T00:00:00Z. The seek logic in theasCursormethod ofQueryableIndexCursorHolderwould be reading2025-02-10T00:00:00Zfrom the projection time column, but moving the offset ahead checking for a value greater than or equal to2025-02-10T00:01:01Zwhich it got from theQueryableIndexTimeBoundaryInspectorof the base table, instead of the correct value it would have from using an inspector of the projection. As a result, the offset is moved forward until the row with next granularity bucket that is larger than __time.Existing tests missed this because the test data starting timestamp lined up evenly with the granularity buckets, so the first row of the __time column was always identical to the first row of projection time columns, so added a new one that targets this scenario specifically and fails without the change to make the projection cursor holder use a projection time boundary inspector.