# Loose versus tight bucket predicates > Source-anchored research for Loose versus tight bucket predicates. Run status: COMPLETED. Parent: [Bucket-level predicate rewriting for measurement operators](https://llms-explorer.com/tree/bucket-level-predicate-rewriting-for-measurement-operators/) · 4 facets · 15 facts · page: https://llms-explorer.com/tree/loose-versus-tight-bucket-predicates/ ## Structure and components - Apache Iceberg's inclusive projection retains partitions that may contain matching rows, while its strict projection proves all rows match and supports residual-filter calculation. This is a logical analogue of loose/tight predicates, not evidence that MongoDB uses Iceberg's implementation. (medium confidence) — [source](https://iceberg.apache.org/spec/) ## Problems, failure modes and limitations - A tight predicate supplies the opposite useful implication: T(B)=true guarantees every event satisfies P. Failure of T does not prove every event fails. Apache Iceberg's strict projection documents this same direction; its inclusive projection documents the loose direction. This is a conceptual analogy across different storage units. (high confidence) — [source](https://raw.githubusercontent.com/mongodb/mongo/master/src/mongo/db/query/timeseries/bucket_spec.h) - When a predicate cannot be rewritten, BucketSpec's kIgnore policy leaves it for evaluation after unpacking; kError reports an error. The documented motivation for kError is partial-index construction, where silently ignoring a requested filter would misrepresent index selectivity. (low confidence) (verified as of 2026-10-30) — [source](https://raw.githubusercontent.com/mongodb/mongo/master/src/mongo/db/query/timeseries/bucket_spec.h) - SERVER-59505 records a historical counterexample: mixing x arrays with x:10 could make control.min.x equal 10, incorrectly excluding the bucket for x < 5 despite matching array elements. Nested object/scalar mixtures can likewise make control.max.x.y fail to represent the maximum of x.y. (low confidence) — [source](https://jira.mongodb.org/browse/SERVER-59505) - MongoDB's measurement equality candidate test brackets the operand between control.min and control.max, with mixed-schema safeguards. Inference: extrema 1 and 9 cannot establish that a measurement equal to 5 exists. (low confidence) (verified as of 2026-10-30) — [source](https://raw.githubusercontent.com/mongodb/mongo/master/src/mongo/db/query/timeseries/bucket_level_comparison_predicate_generator.cpp) ## Comparisons and alternatives - For eligible measurement comparisons, MongoDB's loose scalar bounds use max.x > c for x > c and min.x < c for x < c, preserving inclusive variants; equality requires min.x <= c and max.x >= c. Mixed-schema handling can add an OR branch rather than relying on these inequalities alone. (medium confidence) (verified as of 2026-10-30) — [source](https://raw.githubusercontent.com/mongodb/mongo/master/src/mongo/db/query/timeseries/bucket_level_comparison_predicate_generator.cpp) - SERVER-126494 reports measurements v=1, NaN, 100 with match v<50 followed by an inclusion projection returning no measurements rather than v=1. This is a concrete warning against treating numeric bucket extrema as a complete correctness argument; this claim does not assert that a particular released version remains affected. (low confidence) — [source](https://jira.mongodb.org/browse/SERVER-126494) - When summary statistics cannot prove a part irrelevant, conservative evaluation must retain it. Materialize explicitly permits extra fetched parts but forbids omitted qualifying parts; Iceberg similarly makes inclusive projection a necessary partition condition rather than an exact row test. (medium confidence) — [source](https://materialize.com/blog/how-filter-pushdown-works/) - Conservative pruning must retain uncertainty rather than risk losing matches. SERVER-59505 documents how naive extrema comparisons over mixed arrays and scalars excluded matching buckets; Materialize independently explains why false-positive candidates are acceptable but false-negative pruning is incorrect. (high confidence) — [source](https://jira.mongodb.org/browse/SERVER-59505) - In the inspected MongoDB implementation, comparison-to-null and object/array operands are ineligible for this extrema rewrite. String comparisons also require compatible collation. These restrictions scope the rewrite rather than prohibit evaluating the original query. (low confidence) (verified as of 2026-10-30) — [source](https://raw.githubusercontent.com/mongodb/mongo/master/src/mongo/db/query/timeseries/bucket_level_comparison_predicate_generator.cpp) - Materialize combines nullability and range summaries with conservative abstract interpretation. When the summaries cannot rule out true, they cannot justify skipping a part; this independently illustrates why min/max filtering is an approximation rather than an exact row-membership test. (low confidence) — [source](https://materialize.com/blog/how-filter-pushdown-works/) ## Facts and statements - For event predicate P and bucket B, the safe loose guarantee is: if some event in B satisfies P, L(B) must be true. Thus L(B)=false permits rejection, while L(B)=true does not establish that a matching event exists. Materialize's conservative range analysis gives the same no-false-negative rationale. (high confidence) — [source](https://raw.githubusercontent.com/mongodb/mongo/master/src/mongo/db/query/timeseries/bucket_spec.h) - MongoDB's comparison generator disables tight predicates on non-time measurement fields. Missing measurements do not contribute to control extrema; array-valued controls also introduce implicit element traversal. Consequently, replacing x > 5 with min.x > 5 as proof that every event matches is unsafe. (high confidence) (verified as of 2026-10-30) — [source](https://raw.githubusercontent.com/mongodb/mongo/master/src/mongo/db/query/timeseries/bucket_spec.h) - The comparison generator rejects object/array operands, null comparisons, strings under a differing query collation, computed or projected-away fields, and non-type-bracketing LT/LTE on non-time fields. Its comments identify comparator differences and missing-value semantics as correctness constraints. (low confidence) (verified as of 2026-10-30) — [source](https://raw.githubusercontent.com/mongodb/mongo/master/src/mongo/db/query/timeseries/bucket_level_comparison_predicate_generator.cpp) - For an eligible measurement comparison a > 5, MongoDB uses control.max.a > 5 as the loose comparison, expressed with an internal comparison operator. Mixed-schema safety can add a disjunct, so this is not always the entire generated predicate. (high confidence) (verified as of 2026-10-30) — [source](https://raw.githubusercontent.com/mongodb/mongo/master/src/mongo/db/query/timeseries/bucket_spec.h)