Is your feature request related to a problem or challenge?
In #21077, we set distinct_count to Exact(1) when a filter predicate collapses a column interval to a single value. This works for numeric types (Int32, Float64, etc.) but not for strings (Utf8, Utf8View, LargeUtf8).
The root cause is that next_value_helper() in interval_arithmetic.rs has no implementation for string types - it returns the value unchanged, which prevents the constraint propagation solver from collapsing the interval.
For example, WHERE name = 'hello' should produce NDV=Exact(1) but currently stays at the original Inexact NDV.
Describe the solution you'd like
Detect equality predicates directly in collect_new_statistics (pattern-match BinaryExpr with Operator::Eq + Column + Literal), bypassing interval analysis for the NDV computation.
Describe alternatives you've considered
Implement next_value for strings in interval_arithmetic.rs. This is non-trivial since string ordering depends on locale/collation (see PostgreSQL's collation support for reference), making a universal "next string" ill-defined. That said, it would benefit other interval-based optimizations as well.
Additional context
Is your feature request related to a problem or challenge?
In #21077, we set
distinct_counttoExact(1)when a filter predicate collapses a column interval to a single value. This works for numeric types (Int32, Float64, etc.) but not for strings (Utf8, Utf8View, LargeUtf8).The root cause is that
next_value_helper()ininterval_arithmetic.rshas no implementation for string types - it returns the value unchanged, which prevents the constraint propagation solver from collapsing the interval.For example,
WHERE name = 'hello'should produce NDV=Exact(1) but currently stays at the original Inexact NDV.Describe the solution you'd like
Detect equality predicates directly in
collect_new_statistics(pattern-matchBinaryExprwithOperator::Eq+Column+Literal), bypassing interval analysis for the NDV computation.Describe alternatives you've considered
Implement
next_valuefor strings ininterval_arithmetic.rs. This is non-trivial since string ordering depends on locale/collation (see PostgreSQL's collation support for reference), making a universal "next string" ill-defined. That said, it would benefit other interval-based optimizations as well.Additional context