SQL API: TRIM(view_dimension) expands to nearly the full view and times out

[hank-sq]

Summary

Using TRIM(...) on a view dimension in the SQL API appears to trigger pathological member-expression expansion.

Semantically similar expressions like LOWER(...), LTRIM(...), RTRIM(...), COALESCE(...), and SUBSTRING(...) stay narrow and complete normally, but TRIM(...) causes the normalized query to expand to nearly the full view and eventually time out.

Version

Observed on Cube v1.6.29.

Repro matrix

Works

• view.dimension
• LOWER(view.dimension)
• UPPER(view.dimension)
• COALESCE(view.dimension, '')
• SUBSTRING(view.dimension, 1, 12)
• LTRIM(view.dimension)
• RTRIM(view.dimension)
• LTRIM(LOWER(view.dimension))
• LTRIM(RTRIM(view.dimension))

Fails pathologically

• TRIM(view.dimension)
• TRIM(LOWER(view.dimension))

For the working shapes, the rewritten query stayed narrow (2 measures + 1 dimension in my case).

For the failing shapes, the rewritten query expanded to almost the full view (46 measures + 50 dimensions in my case) and later timed out.

Representative query shape

SELECT
  TRIM(sales_view.item_name) AS item_name,
  MEASURE(sales_view.sales_gross_amount) AS gross_sales,
  MEASURE(sales_view.items_sold_count) AS quantity_sold
FROM sales_view
GROUP BY 1
ORDER BY gross_sales DESC
LIMIT 10

The equivalent workaround completes normally:

SELECT
  LTRIM(RTRIM(sales_view.item_name)) AS item_name,
  MEASURE(sales_view.sales_gross_amount) AS gross_sales,
  MEASURE(sales_view.items_sold_count) AS quantity_sold
FROM sales_view
GROUP BY 1
ORDER BY gross_sales DESC
LIMIT 10

Expected behavior

TRIM(view.dimension) should behave like other simple scalar wrappers on a view dimension and only reference the actually needed members.

Actual behavior

TRIM(view.dimension) causes the SQL API rewrite/planning pipeline to widen the query dramatically and eventually time out.

Why this looks like a Cube bug

This does not look like a generic "function on a view dimension is expensive" issue. Only TRIM(...) reproduces the expansion. Other wrappers on the same dimension do not.

Looking through the source, TRIM appears to be represented specially in the Rust SQL layer, while recent SQL API fixes have focused on generic member-expression and view/dimension-only-expression handling. My guess is that TRIM(...) is falling onto a special expression path where dependency capture for view member expressions is incomplete, and the schema compiler later widens the dependency set during fullKeyQueryAggregate handling.

Related work

• fix(schema-compiler): Handle member expressions in keyDimensions #9083 Handle member expressions in keyDimensions
• fix(schema-compiler): Handle measures with dimension-only member expressions #9335 Handle measures with dimension-only member expressions
• feat(cubesql): Push down DATE_TRUNC expressions as member expressions with granularity #9583 Push down DATE_TRUNC expressions as member expressions with granularity
• fix(schema-compiler): Fix rolling window queries with expressions from SQL API #9603 Fix rolling window queries with expressions from SQL API
• fix(tesseract): Fix rolling window with few time dimensions, filter_group in segments and member expressions #9673 member expressions fixes
• feat(cubesql): Support PatchMeasure for view measures #10571 Support PatchMeasure for view measures

If helpful, I can try to turn this into a more minimal public repro.