Skip to content

sp_QuickieStore: optimize time bucketing in @find_high_impact#707

Merged
erikdarlingdata merged 3 commits intodevfrom
feature/hi-time-bucket-optimization
Mar 23, 2026
Merged

sp_QuickieStore: optimize time bucketing in @find_high_impact#707
erikdarlingdata merged 3 commits intodevfrom
feature/hi-time-bucket-optimization

Conversation

@erikdarlingdata
Copy link
Copy Markdown
Owner

Summary

Moved query_id staging before time bucketing so Step 4 starts from #hi_id_staging_queries (known-small temp table) instead of re-joining through query_store_query. Drops from 4 DMVs to 3 with better cardinality estimates — no join hints needed.

Test plan

  • SQL2022 — StackOverflow2013, hammerdb_tpch, hammerdb_tpcc
  • SQL2016 — StackOverflow2010

🤖 Generated with Claude Code

erikdarlingdata and others added 3 commits March 23, 2026 16:35
sp_QuickieStore: @sort_order tiebreaker for @find_high_impact
The time bucketing query joined the full 4-table DMV chain
(query → plan → runtime_stats → interval) filtered by #hi_interesting.
The optimizer struggled with cardinality estimates on the hash join.

Moved query_id staging (previously Step 5b) to Step 3b so it runs
before time bucketing. Step 4 now starts from #hi_id_staging_queries
(known-small temp table) instead of query_store_query, dropping to
3 DMVs with better cardinality estimates. No join hints needed.

Tested on SQL2022 (StackOverflow2013, hammerdb_tpch, hammerdb_tpcc)
and SQL2016 (StackOverflow2010).

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@erikdarlingdata erikdarlingdata merged commit bfea1cb into dev Mar 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant