Power BI Optimization technique: How to resolve the CallbackDataID in xmSQL

Problem statement 1 : How do you calculate total sales quantity for each product while filtering out sales transactions with a quantity of 1 or less?

Slow Query :

EVALUATE ADDCOLUMNS ( VALUES (Products[Product New]), “Sales”, CALCULATE ( SUMX( Sales, IF (Sales[Quantity_Sold] > 1,Sales[Quantity_Sold]) ) ) )

The Storage Engine (SE) scans the Sales[Quantity_Sold] column and, as it processes each row, delegates the evaluation of the IF condition to the Formula Engine (FE). In this approach, FE is called once per row to evaluate the expression, yet the overall memory footprint of the query remains relatively low.

The query plan includes a CallBackDataID operation. This indicates that during the scan, the Storage Engine temporarily hands control to the Formula Engine to compute the row-level expression—in this case, the IF statement—using the current value of Quantity_Sold . Once the result is returned, SE continues with its aggregation work.

Fast Query :

EVALUATE ADDCOLUMNS ( VALUES ( Products[Product New] ), “Sales”, CALCULATE ( SUM ( Sales[Quantity_Sold] ), Sales[Quantity_Sold] > 1 ) )

we can see that there is no CallBackDataID operation. This means the entire calculation is handled directly by the Storage Engine (SE) without needing assistance from the Formula Engine (FE).

The Storage Engine first identifies the rows where Quantity_Sold is greater than 1 and then calculates the sum only for those qualifying rows. Since the whole operation is performed within SE, the query runs more efficiently and avoids the additional overhead of row-by-row evaluations.

Note : Results produced through CallBackDataID are not stored in the cache, even when the Storage Engine performs part of the work. Therefore, queries that rely heavily on this mixed execution pattern may see limited benefits from cache reuse.