@intentsolutionsio/query-performance-analyzer 1.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,19 @@
1
+ {
2
+ "name": "query-performance-analyzer",
3
+ "version": "1.0.0",
4
+ "description": "Analyze query performance with EXPLAIN plan interpretation, bottleneck identification, and optimization recommendations",
5
+ "author": {
6
+ "name": "Claude Code Plugins",
7
+ "email": "[email protected]"
8
+ },
9
+ "repository": "https://github.com/jeremylongshore/claude-code-plugins",
10
+ "license": "MIT",
11
+ "keywords": [
12
+ "performance",
13
+ "query",
14
+ "optimization",
15
+ "explain",
16
+ "database",
17
+ "agent-skills"
18
+ ]
19
+ }
package/LICENSE ADDED
@@ -0,0 +1,21 @@
1
+ MIT License
2
+
3
+ Copyright (c) 2024-2026 Jeremy Longshore & Contributors
4
+
5
+ Permission is hereby granted, free of charge, to any person obtaining a copy
6
+ of this software and associated documentation files (the "Software"), to deal
7
+ in the Software without restriction, including without limitation the rights
8
+ to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9
+ copies of the Software, and to permit persons to whom the Software is
10
+ furnished to do so, subject to the following conditions:
11
+
12
+ The above copyright notice and this permission notice shall be included in all
13
+ copies or substantial portions of the Software.
14
+
15
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18
+ AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20
+ OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21
+ SOFTWARE.
package/README.md ADDED
@@ -0,0 +1,29 @@
1
+ # Query Performance Analyzer Plugin
2
+
3
+ Analyze query performance with EXPLAIN plan interpretation and optimization recommendations.
4
+
5
+ ## Installation
6
+
7
+ ```bash
8
+ /plugin install query-performance-analyzer@claude-code-plugins-plus
9
+ ```
10
+
11
+ ## Usage
12
+
13
+ The performance agent activates when discussing query performance, EXPLAIN plans, or optimization.
14
+
15
+ ## Features
16
+
17
+ - **EXPLAIN Plan Analysis**: Interpret execution plans
18
+ - **Bottleneck Detection**: Identify performance issues
19
+ - **Index Recommendations**: Suggest optimal indexes
20
+ - **Metrics Interpretation**: Understand performance metrics
21
+ - **Cost Estimation**: Predict query performance
22
+
23
+ ## Example
24
+
25
+ Paste your EXPLAIN output or slow query, and receive detailed analysis with specific optimization recommendations.
26
+
27
+ ## License
28
+
29
+ MIT
@@ -0,0 +1,89 @@
1
+ ---
2
+ name: performance-agent
3
+ description: Analyze and optimize query performance
4
+ ---
5
+ # Query Performance Analyzer Agent
6
+
7
+ You are a database performance analysis expert. Analyze EXPLAIN plans and query performance metrics to identify bottlenecks.
8
+
9
+ ## Analysis Capabilities
10
+
11
+ 1. **EXPLAIN Plan Interpretation**
12
+ - Sequential scans vs index scans
13
+ - Join algorithms (nested loop, hash, merge)
14
+ - Sort operations and memory usage
15
+ - Cost estimates and actual times
16
+ - Row count estimates vs actuals
17
+
18
+ 2. **Performance Metrics**
19
+ - Execution time
20
+ - I/O operations
21
+ - Memory usage
22
+ - CPU time
23
+ - Cache hit ratios
24
+ - Lock contention
25
+
26
+ 3. **Bottleneck Identification**
27
+ - Missing indexes
28
+ - Inefficient joins
29
+ - Suboptimal query structure
30
+ - Data type mismatches
31
+ - Table scans on large tables
32
+ - N+1 query problems
33
+
34
+ ## Key Performance Indicators
35
+
36
+ - **Seq Scan**: Sequential scan (slow on large tables)
37
+ - **Index Scan**: Using an index (good)
38
+ - **Index Only Scan**: Using covering index (best)
39
+ - **Nested Loop**: Join type, good for small datasets
40
+ - **Hash Join**: Join type, good for large datasets
41
+ - **Merge Join**: Join type, requires sorted data
42
+ - **Sort**: Memory or disk sorting
43
+ - **Bitmap Heap Scan**: Multiple index scan
44
+
45
+ ## Example Analysis
46
+
47
+ ### EXPLAIN Output
48
+ ```
49
+ Seq Scan on users (cost=0.00..15000.00 rows=500000 width=100)
50
+ Filter: (created_at > '2024-01-01')
51
+ Rows Removed by Filter: 450000
52
+ ```
53
+
54
+ ### Analysis
55
+ **Problem**: Sequential scan on 500K rows with filter removing 90% of data.
56
+
57
+ **Solution**:
58
+ ```sql
59
+ CREATE INDEX idx_users_created_at ON users(created_at);
60
+ ```
61
+
62
+ **Expected Improvement**: 10-100x faster with index scan touching only 50K rows.
63
+
64
+ ## Performance Checklist
65
+
66
+ - [ ] All WHERE clause columns indexed
67
+ - [ ] JOIN columns indexed
68
+ - [ ] No sequential scans on large tables
69
+ - [ ] Appropriate join algorithms used
70
+ - [ ] Sorts using memory (not disk)
71
+ - [ ] Statistics are up-to-date (ANALYZE)
72
+ - [ ] No data type conversion in WHERE
73
+ - [ ] Covering indexes for frequent queries
74
+
75
+ ## When to Activate
76
+
77
+ - Slow query investigation
78
+ - EXPLAIN plan review
79
+ - Performance optimization requests
80
+ - Database monitoring alerts
81
+ - Query tuning sessions
82
+
83
+ ## Output Format
84
+
85
+ 1. **Current Performance**: Metrics and issues
86
+ 2. **Root Cause**: Why it's slow
87
+ 3. **Recommendations**: Specific fixes
88
+ 4. **Expected Impact**: Performance gains
89
+ 5. **Testing Steps**: How to verify
package/package.json ADDED
@@ -0,0 +1,40 @@
1
+ {
2
+ "name": "@intentsolutionsio/query-performance-analyzer",
3
+ "version": "1.0.0",
4
+ "description": "Analyze query performance with EXPLAIN plan interpretation, bottleneck identification, and optimization recommendations",
5
+ "keywords": [
6
+ "performance",
7
+ "query",
8
+ "optimization",
9
+ "explain",
10
+ "database",
11
+ "agent-skills",
12
+ "claude-code",
13
+ "claude-plugin",
14
+ "tonsofskills"
15
+ ],
16
+ "repository": {
17
+ "type": "git",
18
+ "url": "git+https://github.com/jeremylongshore/claude-code-plugins-plus-skills.git",
19
+ "directory": "plugins/database/query-performance-analyzer"
20
+ },
21
+ "homepage": "https://tonsofskills.com/plugins/query-performance-analyzer",
22
+ "bugs": "https://github.com/jeremylongshore/claude-code-plugins-plus-skills/issues",
23
+ "license": "MIT",
24
+ "author": {
25
+ "name": "Claude Code Plugins",
26
+ "email": "[email protected]"
27
+ },
28
+ "publishConfig": {
29
+ "access": "public"
30
+ },
31
+ "files": [
32
+ "README.md",
33
+ ".claude-plugin",
34
+ "skills",
35
+ "agents"
36
+ ],
37
+ "scripts": {
38
+ "postinstall": "node -e \"console.log(\\\"\\\\n→ This npm package is a tracking/proof artifact. Install the plugin via:\\\\n ccpi install query-performance-analyzer\\\\n or /plugin install query-performance-analyzer@claude-code-plugins-plus in Claude Code\\\\n\\\")\""
39
+ }
40
+ }
@@ -0,0 +1,90 @@
1
+ ---
2
+ name: analyzing-query-performance
3
+ description: |
4
+ Execute use when you need to work with query optimization.
5
+ This skill provides query performance analysis with comprehensive guidance and automation.
6
+ Trigger with phrases like "optimize queries", "analyze performance",
7
+ or "improve query speed".
8
+
9
+ allowed-tools: Read, Write, Edit, Grep, Glob, Bash(psql:*), Bash(mysql:*), Bash(mongosh:*)
10
+ version: 1.0.0
11
+ author: Jeremy Longshore <jeremy@intentsolutions.io>
12
+ license: MIT
13
+ compatible-with: claude-code, codex, openclaw
14
+ tags: [database, performance, analyzing-query]
15
+ ---
16
+ # Query Performance Analyzer
17
+
18
+ ## Overview
19
+
20
+ Analyze slow database queries using execution plans, wait statistics, and I/O metrics across PostgreSQL, MySQL, and MongoDB. This skill captures EXPLAIN output, identifies sequential scans on large tables, detects missing indexes, measures buffer cache hit ratios, and produces actionable optimization recommendations ranked by expected performance impact.
21
+
22
+ ## Prerequisites
23
+
24
+ - Database credentials with permissions to run `EXPLAIN ANALYZE` (PostgreSQL), `EXPLAIN FORMAT=JSON` (MySQL), or `explain()` (MongoDB)
25
+ - `pg_stat_statements` extension enabled for PostgreSQL (provides aggregated query statistics)
26
+ - Access to slow query logs or performance_schema (MySQL)
27
+ - Baseline query execution times for comparison
28
+ - `psql`, `mysql`, or `mongosh` CLI tools installed
29
+
30
+ ## Instructions
31
+
32
+ 1. Identify the slowest queries by examining `pg_stat_statements` (PostgreSQL): `SELECT query, calls, mean_exec_time, total_exec_time FROM pg_stat_statements ORDER BY mean_exec_time DESC LIMIT 20`. For MySQL, enable and query the slow query log or `performance_schema.events_statements_summary_by_digest`.
33
+
34
+ 2. Run `EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON)` on each slow query in PostgreSQL, or `EXPLAIN ANALYZE FORMAT=JSON` in MySQL. Capture the full execution plan including actual row counts, loop iterations, and buffer usage.
35
+
36
+ 3. Analyze the execution plan for these red flags:
37
+ - **Sequential scans** on tables with >10,000 rows (indicates missing index)
38
+ - **Nested loop joins** with high outer row counts (consider hash join or merge join)
39
+ - **Sort operations** without index support (adding a covering index eliminates the sort)
40
+ - **High `rows_removed_by_filter`** relative to `rows` (predicate not selective enough)
41
+ - **Bitmap heap scans** with high recheck rate (index selectivity too low)
42
+
43
+ 4. Check buffer cache performance: `SELECT heap_blks_read, heap_blks_hit, heap_blks_hit::float / (heap_blks_hit + heap_blks_read) AS cache_hit_ratio FROM pg_statio_user_tables WHERE relname = 'table_name'`. A ratio below 0.95 suggests the working set exceeds available shared_buffers.
44
+
45
+ 5. Evaluate index usage with `SELECT indexrelname, idx_scan, idx_tup_read, idx_tup_fetch FROM pg_stat_user_indexes WHERE schemaname = 'public' ORDER BY idx_scan ASC`. Indexes with zero scans are unused and waste write performance.
46
+
47
+ 6. Check for table bloat using `SELECT relname, n_live_tup, n_dead_tup, n_dead_tup::float / GREATEST(n_live_tup, 1) AS dead_ratio FROM pg_stat_user_tables WHERE n_dead_tup > 1000 ORDER BY dead_ratio DESC`. A dead tuple ratio above 0.2 indicates the table needs VACUUM.
48
+
49
+ 7. For each identified issue, generate a specific recommendation: CREATE INDEX statement with the exact columns, query rewrite suggestions, or configuration parameter adjustments.
50
+
51
+ 8. Estimate the performance impact of each recommendation by comparing the EXPLAIN plan before and after applying the change on a staging database or by analyzing the expected row reduction from new indexes.
52
+
53
+ 9. Prioritize recommendations by impact-to-effort ratio: index additions (high impact, low effort) before query rewrites (medium impact, medium effort) before schema changes (high impact, high effort).
54
+
55
+ 10. Generate a performance analysis report with before/after execution plans, estimated improvements, and implementation priority ranking.
56
+
57
+ ## Output
58
+
59
+ - **Slow query inventory** with execution frequency, mean/P95 duration, and total time consumed
60
+ - **Annotated execution plans** highlighting sequential scans, sort bottlenecks, and join inefficiencies
61
+ - **Index recommendations** as ready-to-execute CREATE INDEX statements with expected impact
62
+ - **Query rewrite suggestions** with original and optimized SQL side by side
63
+ - **Buffer cache analysis** with shared_buffers sizing recommendations
64
+ - **Performance report** ranking all findings by severity and implementation priority
65
+
66
+ ## Error Handling
67
+
68
+ | Error | Cause | Solution |
69
+ |-------|-------|---------|
70
+ | `EXPLAIN ANALYZE` takes too long on production | Query modifies data or runs for minutes | Use `EXPLAIN` without `ANALYZE` for estimated plans; run `EXPLAIN ANALYZE` on staging with representative data |
71
+ | `pg_stat_statements` not available | Extension not installed or not in shared_preload_libraries | Run `CREATE EXTENSION pg_stat_statements`; add to `shared_preload_libraries` in postgresql.conf and restart |
72
+ | Execution plan differs between staging and production | Different data distribution, statistics, or configuration | Run `ANALYZE` on staging tables to update statistics; match `work_mem`, `random_page_cost`, and `effective_cache_size` settings |
73
+ | Index recommendation causes slow writes | Too many indexes on a write-heavy table | Limit indexes to 5-7 per table; use partial indexes to reduce scope; consider covering indexes to replace multiple single-column indexes |
74
+ | Query plan uses wrong index | Stale statistics or cost model miscalculation | Run `ANALYZE table_name` to refresh statistics; adjust `random_page_cost` for SSD storage; use `SET enable_seqscan = off` to test index plans |
75
+
76
+ ## Examples
77
+
78
+ **Optimizing a dashboard aggregate query**: A query computing daily revenue with `GROUP BY date` and `JOIN` across orders and line_items takes 12 seconds. EXPLAIN reveals a sequential scan on line_items (5M rows). Adding a composite index on `(order_id, created_at)` with `INCLUDE (amount)` reduces execution to 200ms by enabling an index-only scan.
79
+
80
+ **Diagnosing N+1 query pattern**: Application loads a list page showing 50 products, each with a separate query for category name. `pg_stat_statements` reveals `SELECT name FROM categories WHERE id = $1` called 50 times per page load. Resolution: rewrite as a single JOIN query or implement eager loading in the ORM.
81
+
82
+ **Identifying bloated table causing cache misses**: Buffer cache hit ratio drops to 0.78 on the sessions table. Investigation reveals 80% dead tuples due to aggressive INSERT/DELETE cycling without autovacuum tuning. Setting `autovacuum_vacuum_scale_factor = 0.01` and running `VACUUM FULL` restores cache hit ratio to 0.99.
83
+
84
+ ## Resources
85
+
86
+ - PostgreSQL EXPLAIN documentation: https://www.postgresql.org/docs/current/using-explain.html
87
+ - pg_stat_statements reference: https://www.postgresql.org/docs/current/pgstatstatements.html
88
+ - MySQL EXPLAIN output format: https://dev.mysql.com/doc/refman/8.0/en/explain-output.html
89
+ - Use The Index, Luke (SQL indexing guide): https://use-the-index-luke.com/
90
+ - pgMustard EXPLAIN visualizer: https://www.pgmustard.com/
@@ -0,0 +1,5 @@
1
+ # Assets
2
+
3
+ Bundled resources for query-performance-analyzer skill
4
+
5
+ - [ ] example_explain_plans/: A directory containing example EXPLAIN plans for various databases and query types.
@@ -0,0 +1,4 @@
1
+ # References
2
+
3
+ Bundled resources for query-performance-analyzer skill
4
+
@@ -0,0 +1,11 @@
1
+ # Scripts
2
+
3
+ Bundled resources for query-performance-analyzer skill
4
+
5
+ - [x] explain_plan_parser.py: Parses EXPLAIN plan output and extracts key metrics.
6
+ - [x] index_advisor.py: Analyzes query patterns and recommends optimal indexes.
7
+ - [x] query_rewriter.py: Suggests alternative query formulations for better performance.
8
+
9
+
10
+ ## Auto-Generated
11
+ Scripts generated on 2025-12-10 03:48:17