Was macht dieser Skill?
/pg-perf ist ein Multi-Tool-Workflow, der drei einzelne MCP-Tools in Sequenz aufruft und die Ergebnisse zu einem vollständigen Performance-Assessment zusammenführt. Statt drei Tools einzeln aufzurufen und die Ergebnisse manuell zu korrelieren, liefert der Skill einen strukturierten Bericht mit einem Gesamtscore von 0 bis 100.
Workflow-Phasen
- Phase 1 — Slow Queries:
pg_slow_query_digestidentifiziert die langsamsten Queries nach Gesamtlaufzeit - Phase 2 — Fehlende Indizes:
pg_index_advisoranalysiert Sequential Scans und schlägt Indizes vor - Phase 3 — Cache-Effizienz:
pg_cache_hit_ratioprüft die Buffer-Cache-Trefferquote - Phase 4 — Aggregierter Bericht: Ergebnisse werden korreliert und ein Gesamtscore berechnet
Wie wird er aufgerufen?
Verbindung herstellen
Jeder Skill beginnt mit einer Datenbankverbindung. Die Enterprise-Plattform unterstützt mehrere Profile — ideal für Multi-Cluster-Setups:
▶ Calling tools...
→ pg_connect { "profile": "production-db" }
{
"status": "connected",
"database": "mcp_test",
"version": "PostgreSQL 16.x",
"host": "db.example.com"
}
Claude CLI (natürliche Sprache)
▶ Calling tools...
→ Phase 1/4: pg_slow_query_digest {}
3 langsame Queries gefunden (Top: SELECT * FROM perf.transactions WHERE status = $1)
Langsamste: 847 Aufrufe, Ø 14.2ms, Gesamt: 12.0s
→ Phase 2/4: pg_index_advisor {}
2 fehlende Indizes erkannt:
→ CREATE INDEX idx_transactions_status ON perf.transactions(status)
→ CREATE INDEX idx_orders_customer_id ON app.orders(customer_id)
→ Phase 3/4: pg_cache_hit_ratio {}
Cache Hit Ratio: 94.7% (Heap), 98.2% (Index)
→ Heap-Cache unter 95% — mehr shared_buffers empfohlen
→ Phase 4/4: Aggregierter Bericht
╔══════════════════════════════════════╗
║ Performance Score: 72 / 100 ║
╠══════════════════════════════════════╣
║ Slow Queries : 3 gefunden ║
║ Fehlende Indizes : 2 vorgeschlagen ║
║ Cache Hit Ratio : 94.7% (Heap) ║
║ Empfehlung : Indizes + RAM ║
╚══════════════════════════════════════╝
MCP Protocol (Skill-Definition)
const result = await client.callTool("/pg-perf", {});
// Response:
{
"skill": "/pg-perf",
"tools": [
"pg_slow_query_digest",
"pg_index_advisor",
"pg_cache_hit_ratio"
],
"phases": 4,
"output": {
"score": 72,
"slow_queries": 3,
"missing_indexes": 2,
"cache_hit_ratio": { "heap": 94.7, "index": 98.2 },
"recommendations": [
"CREATE INDEX idx_transactions_status ON perf.transactions(status)",
"CREATE INDEX idx_orders_customer_id ON app.orders(customer_id)",
"Increase shared_buffers from 128MB to 256MB"
]
}
}
Was passiert unter der Haube?
Der Skill orchestriert die drei Tools in einer festen Reihenfolge. Jedes Tool liefert strukturierte Daten, die in der Aggregationsphase zusammengeführt werden:
Phase 1: Slow Query Digest
Analysiert pg_stat_statements und identifiziert Queries mit dem höchsten Häufigkeit × Dauer-Produkt. Die Top-N Queries werden als Eingabe für Phase 2 verwendet.
Phase 2: Index Advisor
Prüft pg_stat_user_tables auf Tabellen mit hohem Sequential-Scan-Anteil und generiert CREATE INDEX-Vorschläge. Korreliert mit den Slow Queries aus Phase 1.
Phase 3: Cache Hit Ratio
Berechnet die Buffer-Cache-Trefferquote aus pg_statio_user_tables. Ein Wert unter 95% (Heap) oder 99% (Index) deutet auf zu wenig shared_buffers hin.
Phase 4: Aggregation
Berechnet den Gesamtscore anhand einer gewichteten Formel:
- 40% — Slow Query Severity (Anzahl × durchschnittliche Dauer)
- 30% — Missing Index Impact (geschätzter Performance-Gewinn)
- 30% — Cache Efficiency (Abweichung vom 99%-Ziel)
Praxis-Tipp: Ein Score unter 60 erfordert sofortiges Handeln. Zwischen 60 und 80 gibt es klare Optimierungsmöglichkeiten. Über 80 ist die Datenbank in gutem Zustand.
Was testet die Testsuite?
Die Testsuite validiert den gesamten Workflow gegen eine PostgreSQL-Instanz mit 100.000 Transaktionen in perf.transactions und bewusst fehlenden Indizes:
✓ /pg-perf > pg_index_advisor detects missing indexes on perf.transactions
Test Files 1 passed (1)
Tests 2 passed (2)
Duration 1.8s
Testdaten-Szenario
Die Seed-Datenbank enthält:
- perf.transactions — 100.000 Zeilen mit Betrag, Währung, Status, Zeitstempel (kein Index auf
status) - app.orders — Bestellungen ohne Index auf
customer_id(triggert Sequential Scan) - app.users — 4 User mit realistischem Query-Muster für pg_stat_statements
- pg_stat_statements — Automatisch befüllt durch vorherige Testläufe
Zusammenfassung
/pg-perf ersetzt den manuellen Dreischritt aus Slow-Query-Analyse, Index-Prüfung und Cache-Check durch einen einzigen Befehl. Der aggregierte Score macht Performance-Trends über die Zeit vergleichbar — ideal für wöchentliche Health Checks oder Post-Deployment-Validierung.