Document filter operator-matching limitation for pre-aggregates - #1089
Merged
Conversation
Contributor
Author
|
Preview deployment for your docs. Learn more about Mintlify Previews.
|
Contributor
🤖 Documentation Bot✅ All checks passed! No issues found. |
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
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.
Summary
Pre-aggregate filter matching only compares filters that use the same operator. An absolute date filter (
is 2026-01-15) will not match a relative pre-aggregate filter (inThePast 30 days) even when the selected date falls inside the window, and vice versa. Queries with a mismatched operator fall back to the warehouse.This is a known architectural limitation (no filter AST, so no true applied-filter ⊆ materialized-filter check). The docs previously described filter compatibility only as "same or narrower / broader or incompatible", and every example was same-operator (
inThePast NvsinThePast M), so a reader would reasonably expect a specific date inside a rolling window to count as narrower.Changes
references/pre-aggregates/overview.mdx— Added a<Warning>to the "Filtered pre-aggregates" section explaining the same-operator requirement and pointing readers to the same relative operator as the workaround.references/pre-aggregates/getting-started.mdx— Added a mixed-operator counter-example (order_date is 2026-01-15cannot use a pre-aggregate filteredinThePast 52 weeks) to the "How query matching works with filters" list, plus a<Warning>with the same detail as overview.references/pre-aggregates/monitoring.mdx— Expanded the "Pre-aggregate filter not satisfied" miss-reason row to call out the same-operator requirement and swap the misleading "narrow the query filter" hint for "match the pre-aggregate filter's operator".Context
Prompted by a Slack thread (C03MCQ08UKS) where a customer's rolling-window pre-aggregate missed on an absolute-date query, and the team confirmed this is a documented-limitation situation rather than a bug fix.
Generated by Mintlify Agent.
Requested by: irakli@lightdash.com via Slack
Mintlify session: slack_1786344251.285279_C03MCQ08UKS