Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
{"query":{"type":"string","required":false,"description":"Query to optimize"},"table":{"type":"string","required":false,"description":"Table to analyze"}}
-- Uses the index ✓WHERE date_trunc('day', sold_at ATTIME ZONE 'UTC')::dateBETWEEN'2025-01-01'AND'2025-01-31'-- Does NOT use the index ✗WHERE (sold_at ATTIME ZONE 'UTC')::dateBETWEEN'2025-01-01'AND'2025-01-31'
ALTER TABLE sale ADD sold_at_date DATE
GENERATED ALWAYS AS (date_trunc('day', sold_at ATTIME ZONE 'UTC'));
Now queries use the virtual column:
SELECT sold_at_date, SUM(charged)
FROM sale
WHERE sold_at_date BETWEEN'2025-01-01'AND'2025-01-31'GROUPBY1;
Benefits:
Smaller index
Faster queries
No discipline required — column guarantees correct expression
No ambiguity about timezones
Limitation: PostgreSQL 18 doesn't support indexes directly on virtual columns (yet).
Technique 3: Hash Index for Uniqueness
The Problem
You have a table with large URLs:
CREATE TABLE urls (
id INTPRIMARY KEY,
url TEXT NOT NULL,
data JSON
);
You add a unique B-Tree index:
CREATEUNIQUE INDEX urls_url_unique_ix ON urls(url);
Size
Table: 160 MB
B-Tree index: 154 MB
The index is almost as large as the table because B-Tree stores actual values in leaf blocks.
The Solution
Use an exclusion constraint with a hash index:
ALTER TABLE urls
ADD CONSTRAINT urls_url_unique_hash
EXCLUDE USING HASH (url WITH=);
Index
Size
B-Tree
154 MB
Hash
32 MB
The hash index is 5x smaller because it stores hash values, not the actual URLs.
Uniqueness Is Enforced
INSERT INTO urls (id, url) VALUES (1000002, 'https://example.com');
-- ERROR: conflicting key value violates exclusion constraint
Queries Still Fast
EXPLAIN ANALYZE SELECT*FROM urls WHERE url ='https://example.com';
Index Scan using urls_url_unique_hash on urls
Execution Time: 0.022 ms -- Faster than B-Tree's 0.046 ms!
Limitations
Feature
B-Tree Unique
Hash Exclusion
Foreign key reference
✓
✗
ON CONFLICT (column)
✓
✗
ON CONFLICT ON CONSTRAINT
✓
✓ (DO NOTHING only)
ON CONFLICT DO UPDATE
✓
✗
MERGE
✓
✓
Workaround: Use MERGE
Instead of INSERT ... ON CONFLICT DO UPDATE:
MERGEINTO urls t
USING (VALUES (1000004, 'https://example.com')) AS s(id, url)
ON t.url = s.url
WHEN MATCHED THENUPDATESET id = s.id
WHENNOT MATCHED THENINSERT (id, url) VALUES (s.id, s.url);
Quick Reference
Diagnostic Queries
Check index sizes:
\di+ table_*
Compare index to table size:
SELECT
relname AS name,
pg_size_pretty(pg_relation_size(oid)) AS size
FROM pg_class
WHERE relname LIKE'your_table%'ORDERBY pg_relation_size(oid) DESC;
Check constraint_exclusion setting:
SHOW constraint_exclusion;
Decision Tree
Is the query scanning impossibly?
├── Yes → Enable constraint_exclusion
└── No
↓
Is index nearly as large as table?
├── Yes, timestamp column → Function-based index on date
├── Yes, large text column → Hash exclusion constraint
└── No → Standard B-Tree is fine