What is the problem the feature request solves?
Follow-up to #6262.
The predicates in CometInMemoryCachePruningSuite do not directly test integer min/max boundaries. The selected IDs in id IN (1, 9, 49) fall inside their batches, while n IS NULL checks null counts. As a result, an integer upper bound that is one too small can go undetected by this suite.
Describe the potential solution
Add n = 5 to the shared predicate list. In the existing fixture, the matching batch contains only n = 5, so this predicate exercises both its lower and upper bounds.
Verify all three writer paths: native Arrow, Spark columnar, and row input. Keep the independent expected-result and pruning assertions. With the current fixture, the predicate should return IDs 20–23 and retain one four-row batch.
Additional context
Suggested during review of #6262:
#6262 (comment)
Related original issue: #6203.
What is the problem the feature request solves?
Follow-up to #6262.
The predicates in
CometInMemoryCachePruningSuitedo not directly test integer min/max boundaries. The selected IDs inid IN (1, 9, 49)fall inside their batches, whilen IS NULLchecks null counts. As a result, an integer upper bound that is one too small can go undetected by this suite.Describe the potential solution
Add
n = 5to the shared predicate list. In the existing fixture, the matching batch contains onlyn = 5, so this predicate exercises both its lower and upper bounds.Verify all three writer paths: native Arrow, Spark columnar, and row input. Keep the independent expected-result and pruning assertions. With the current fixture, the predicate should return IDs 20–23 and retain one four-row batch.
Additional context
Suggested during review of #6262:
#6262 (comment)
Related original issue: #6203.