dax-optimization

Capture a server-side trace and the DAX query plan, then split total duration into Storage Engine and Formula Engine time. SE-bound queries need cardinality and data volume reduction; FE-bound queries need fewer callbacks, less materialization, and set-based logic.

CallbackDataID means the Storage Engine called back into the single-threaded Formula Engine mid-scan, disabling VertiPaq optimizations. It is usually caused by IF, IFERROR, raw division, or conditional logic inside iterators, and is the top red flag in a physical plan.

Split datetime columns into separate date and time columns, round or bucket numeric values, convert high-cardinality floating point columns to fixed decimal or integer, and drop unused keys. Focus on columns the query actually references.

For a simple column predicate, use KEEPFILTERS(Table[Column] = value) so the predicate is pushed to the Storage Engine. FILTER over an entire table materializes all rows and forces row-by-row Formula Engine evaluation, especially when testing a measure.

Yes. Add a rule object to both JSON copies of the rule catalog, and if it needs a new metric or collection, extend build_context() in _dax_optimization.py. Each rule needs an id, severity, condition, message, recommendation, and at least one authoritative reference.

Each rule declares required artifacts such as trace, query plan, or Vertipaq statistics, and is skipped when any are missing. Vertipaq rules are also skipped when all Data column cardinalities are 1, since there is nothing meaningful to analyze.