Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →nwave-ai/nw-query-optimization
SQL and NoSQL query optimization techniques, indexing strategies, execution plan analysis, JOIN algorithms, cardinality estimation, and database-specific query patterns
Passed 22 of 22 test cases with the skill, and 20 of 22 without it.
2 fixed20 passed either way0 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 2 test cases the skill fixed. Same model, same prompt, with and without the skill.
I have a PostgreSQL table for customer orders with millions of rows. My current query filters by created_at date range, filters by customer_id exact match, and sorts by total_amount while retrieving customer name and email. It is running extremely slowly. Can you analyze this scenario and provide me with a recommended indexing strategy DDL statement and a rewritten query, explaining how the index keys should be ordered for this workload?
| Checked | Without skill | With skill |
|---|---|---|
| Recommends ordering compound index columns as equality first, sort second, and range last | Missed | Passed |
| Places customer_id before total_amount and created_at in the index definition | Passed | Passed |
The instructions your model reads when the skill loads.
Modern relational DBs use cost-based optimizers (CBO): generate plan candidates -> estimate cost via statistics (row counts, distributions, selectivity) -> select lowest I/O/CPU/memory plan. Stale statistics lead to suboptimal plans.
Validate optimization with EXPLAIN before and after changes.
-- PostgreSQL (add ANALYZE for actual runtime stats)
EXPLAIN ANALYZE SELECT order_id, total FROM orders WHERE customer_id = 12345;
-- MySQL: EXPLAIN FORMAT=JSON ... | SQL Server: SET STATISTICS IO ON
Key indicators: Seq Scan/Table Scan = missing index | Index Scan/Seek = efficient | Hash Join = large equality joins | Nested Loop = small/indexed inner | Merge Join = pre-sorted inputs | Sort = watch disk spills
Supports: equality, range, sorting, prefix matching | O(log n) lookup | General-purpose, all major DBs default
Equality only | O(1) lookup | High-cardinality exact-match | No range/sorting/pattern support
Include all query columns in index -> eliminates table access (index-only scan) | Trade-off: larger index, slower writes
-- Covering index for: SELECT name, email FROM users WHERE status = 'active'
CREATE INDEX idx_users_status_covering ON users(status) INCLUDE (name, email);
test cases passed, vs 20 / 22 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.