mirror of
https://github.com/supabase/agent-skills.git
synced 2026-01-26 19:09:51 +08:00
a1b0257ec2
* Add 30 PostgreSQL best practices rules Rules organized in 8 categories: - Query Performance (5): indexes, partial indexes, composite, covering, types - Connection Management (4): pooling, limits, idle timeout, prepared statements - Schema Design (4): data types, primary keys, foreign key indexes, partitioning - Concurrency & Locking (4): short transactions, SKIP LOCKED, advisory, deadlocks - Security (3): RLS basics, RLS performance, privileges - Data Access Patterns (4): N+1 queries, pagination, upsert, batch inserts - Monitoring (3): EXPLAIN ANALYZE, pg_stat_statements, VACUUM/ANALYZE - Advanced Features (3): JSONB indexing, full-text search, CTE materialization Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * Update skills/postgresql-best-practices/rules/schema-primary-keys.md Co-authored-by: samrose <samuel.rose@gmail.com> * Update skills/postgresql-best-practices/rules/lock-deadlock-prevention.md Co-authored-by: samrose <samuel.rose@gmail.com> * resolve merge conflicts from postgres team suggestions * Delete GETTING_STARTED.md * Restore all 30 rule files that were lost during rebase * update agents.md * remove postgres 11 mention to advanced cte optimization * update agents.md * replace advanced cte with check contraints * replace check contraints with schema lowercase identifiers --------- Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com> Co-authored-by: samrose <samuel.rose@gmail.com>
1.4 KiB
1.4 KiB
title, impact, impactDescription, tags
| title | impact | impactDescription | tags |
|---|---|---|---|
| Use EXPLAIN ANALYZE to Diagnose Slow Queries | LOW-MEDIUM | Identify exact bottlenecks in query execution | explain, analyze, diagnostics, query-plan |
Use EXPLAIN ANALYZE to Diagnose Slow Queries
EXPLAIN ANALYZE executes the query and shows actual timings, revealing the true performance bottlenecks.
Incorrect (guessing at performance issues):
-- Query is slow, but why?
select * from orders where customer_id = 123 and status = 'pending';
-- "It must be missing an index" - but which one?
Correct (use EXPLAIN ANALYZE):
explain (analyze, buffers, format text)
select * from orders where customer_id = 123 and status = 'pending';
-- Output reveals the issue:
-- Seq Scan on orders (cost=0.00..25000.00 rows=50 width=100) (actual time=0.015..450.123 rows=50 loops=1)
-- Filter: ((customer_id = 123) AND (status = 'pending'::text))
-- Rows Removed by Filter: 999950
-- Buffers: shared hit=5000 read=15000
-- Planning Time: 0.150 ms
-- Execution Time: 450.500 ms
Key things to look for:
-- Seq Scan on large tables = missing index
-- Rows Removed by Filter = poor selectivity or missing index
-- Buffers: read >> hit = data not cached, needs more memory
-- Nested Loop with high loops = consider different join strategy
-- Sort Method: external merge = work_mem too low
Reference: EXPLAIN