Skip to content

sp_QuickieStore: optimize time bucketing in @find_high_impact#708

Merged
erikdarlingdata merged 2 commits intomainfrom
dev
Mar 23, 2026
Merged

sp_QuickieStore: optimize time bucketing in @find_high_impact#708
erikdarlingdata merged 2 commits intomainfrom
dev

Conversation

@erikdarlingdata
Copy link
Copy Markdown
Owner

Summary

Time bucketing now starts from staged query_ids (3 DMVs) instead of re-joining the full 4-table chain. Better cardinality estimates, no join hints.

Tested on SQL2022 (SO2013, TPC-H, TPC-C) and SQL2016.

🤖 Generated with Claude Code

erikdarlingdata and others added 2 commits March 23, 2026 18:40
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>
…ptimization

sp_QuickieStore: optimize time bucketing in @find_high_impact
@erikdarlingdata erikdarlingdata merged commit ad6d3fb into main Mar 23, 2026
9 checks passed
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