Before/after comparison mode for query grids

[erikdarlingdata]

Summary

The MCP analysis engine already supports time-period comparison via `compare_analysis`. The UI should expose a similar concept for query performance data, letting users see how queries changed between two time periods.

Proposed Feature

A toggle or split-view on query grids that shows "this period vs baseline" side by side. After selecting a time range (via the slicer or time controls), toggle comparison mode to see the same queries from a prior period with delta columns.

Example Flow

1. User selects a 4-hour window in the slicer (today 2pm-6pm)
2. User enables "Compare" toggle
3. Grid shows the same queries from yesterday 2pm-6pm alongside today's data
4. Delta columns appear: "Duration Δ +340%", "CPU Δ -12%", "Executions Δ +500%"
5. User immediately sees which queries regressed and which improved

Delta Columns

Column	Shows
Avg Duration Δ	Percentage change in average duration
Avg CPU Δ	Percentage change in average CPU
Execution Count Δ	Percentage change in execution count
Avg Reads Δ	Percentage change in logical reads

Design Notes

• Pairs naturally with the slicer — the slicer selects "now," comparison shows "vs. then"
• Baseline period options: same window yesterday, same window last week, custom
• Delta columns should be color-coded: red for regression, green for improvement
• Sorting by delta columns lets users find the biggest regressions instantly
• Higher complexity: requires baseline data fetch + join logic + split UI
• Applies to both Dashboard and Lite

[erikdarlingdata]

Implementation order: Lite first, then port to Dashboard once the pattern is validated. This avoids the complexity of iterating on both apps simultaneously.

[erikdarlingdata]

Implementation Notes

Query hash matching works for the common case — same queries running differently after a change. The edge case of a rewritten query (new hash) is real but actually useful information: old hash drops off, new hash appears. That tells you something changed.

Procedure matching is straightforward — match on schema + object name.

Recommended approach:

• Start with procedure stats comparison (reliable key: schema.object_name)
• Add query stats comparison by query_hash (covers 90% of cases)
• Query Store comparison by query_id (stable across plan changes)
• The "missing" queries (old hash gone, new hash appeared) could be shown in a separate "New/Removed" section

Deferred for a fresh session — this deserves careful implementation. The slicer + time picker infrastructure is in place from #681/#682/#684 work.