You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently support time range adjustments when users pass in explicit start and end time values. These interfaces are only really exposed in the CLI, however, and are not available in, e.g., metric filter specifications in the YAML.
We have decided to allow some limited-scope detection of time range filter expressions across all input modes such that we can do the granularity and time-window adjustments on the filter spec pre-rendering, much as we do with the date/time literals passed in start_time/end_time, rather than via datetime function manipulation.
The current idea is to do a simple regex match to detect the most common filter expressions for setting a time range - i.e., one bounded by time literals - on a single time dimension (notably metric_time). This will allow users to trigger pushdown by doing fairly natural things like adding a single filter for `metric_time BETWEEN '2021-01-01' AND '2021-01-31'.
tlento
changed the title
Enable automatic time range adjustments for standard sets of time filter predicates
[SL-1630] Enable automatic time range adjustments for standard sets of time filter predicates
Jan 29, 2024
We currently support time range adjustments when users pass in explicit start and end time values. These interfaces are only really exposed in the CLI, however, and are not available in, e.g., metric filter specifications in the YAML.
We have decided to allow some limited-scope detection of time range filter expressions across all input modes such that we can do the granularity and time-window adjustments on the filter spec pre-rendering, much as we do with the date/time literals passed in start_time/end_time, rather than via datetime function manipulation.
The current idea is to do a simple regex match to detect the most common filter expressions for setting a time range - i.e., one bounded by time literals - on a single time dimension (notably metric_time). This will allow users to trigger pushdown by doing fairly natural things like adding a single filter for `metric_time BETWEEN '2021-01-01' AND '2021-01-31'.
From SyncLinear.com | SL-1630
The text was updated successfully, but these errors were encountered: