Microsoft's October 25, 2026 Azure SQL support investigation shows how recorded StatMan statements in Query Store can help examine the work behind statistics calculations. The case began with small variations in query latency during a customer's stress test. It is diagnostic guidance, not a new database feature or a universal explanation for slower queries. Microsoft's investigation.
The useful distinction is between measuring internal work and proving its effect on an application. Those are related questions, but they need different evidence.
Start with the Application's Observation
My proposed investigation record would identify the affected query or transaction, the comparison period, and the difference the application team actually observed.
Keep the original workload evidence intact before exploring a possible explanation. Include representative latency measurements, relevant release changes, and the operating conditions during the test.
Write the hypothesis narrowly: statistics-related work may have contributed during this period. That gives the team something to test without deciding the answer before reviewing the data.
Inspect Recorded Statements, Not an Internal Function Call
Microsoft examines engine-generated SELECT StatMan(...) statements already present in Query Store. The article warns that a text match needs inspection and that an empty result does not prove statistics updates did not occur. Capture and interpretation boundaries.
I would first ask the database owner whether the relevant records are available and retained for the period. If they are not, document that evidence gap rather than treating it as an application finding.
Use Microsoft's linked inspection query as a reviewed starting point for an approved investigation. Do not invoke an undocumented internal function simply because its name appears in a recorded statement.
Keep any decision to add a diagnostic capture separate from the read-only review of existing records. It should have a defined scope and an owner.
Respect Query Store's Aggregation and Units
The runtime-statistics reference documents duration and CPU in microseconds and logical reads as counts of 8-KB pages. It also explains that an active interval can have multiple rows requiring aggregation by plan, execution type, and interval.
Microsoft's support query weights averages by execution count. Its time filter includes overlapping intervals in full, and its first and last execution timestamps describe completion times. Query explanation.
My report would retain the interval boundaries and execution counts alongside any converted values. A precise-looking number should not conceal a broader measurement window.
Before comparing two periods, confirm that the grouping and units are consistent. Ask a second engineer to reproduce a small portion of the calculation before using the totals to support a change.
Separate Accumulated Work from Elapsed Time
The support article cautions that summed statement duration is not end-to-end wall-clock time. It also distinguishes recorded StatMan consumption from the full statistics update and from application latency. Limits of the measurement.
I would present the internal-work observations next to the application's performance timeline, not replace one with the other. Check whether the periods align and what competing explanations remain.
If the evidence suggests a relationship, agree on a bounded follow-up test. Keep the workload, measurement method, and acceptance criteria stable enough to make the comparison useful.
Do not disable statistics behavior or change database settings merely to make a correlation disappear. A production change needs a stronger case than the presence of an expensive-looking internal statement.
Practical Cloud Engineer Takeaway
Define the application symptom before choosing an explanation.
Verify that Query Store contains relevant recorded statements.
Inspect text matches and preserve capture limitations.
Keep execution counts, units, and interval boundaries visible.
Correlate internal work with workload evidence before changing behavior.
Who Should Care?
Azure SQL operators, database performance engineers, and application teams reviewing small but repeatable latency differences.
Bottom Line
Query Store can expose useful historical evidence about statistics calculations when the records are available. The engineering value is a more defensible investigation—not a shortcut from one internal statement to a production tuning decision.
No database query, statistics update, diagnostic capture, or performance test was executed for this article.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments