Why should you care?

Before shipping a Swiggy report SQL to production, EXPLAIN ANALYZE on PostgresVerse staging catches seq scans that looked fine on 1000 rows.

See it live — copy this example

Run in pgAdmin or psql.

EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT)
SELECT o.order_id, c.email
FROM orders o
JOIN customers c ON c.customer_id = o.customer_id
WHERE o.created_at >= now() - interval '1 day';

What happened?

• Planner picks join order and scan types.
• Actual rows vs estimated rows reveal bad stats.
• Buffers shows shared hit/read — disk reads hurt latency.

Practice next

1. Run EXPLAIN without ANALYZE first — no execution cost.
2. Add ANALYZE on staging copy with realistic data volume.
3. Compare estimated rows vs actual in each plan node.
4. Use FORMAT JSON and paste into explain.dalibo.com visualizer.
5. Compare plans before/after adding a composite index.

Remember

EXPLAIN = plan only; ANALYZE = plan plus execution stats. Mismatch in row estimates signals stats or stats target issues. BUFFERS highlights I/O bottlenecks.

PostgresVerse release gate

PR checklist requires EXPLAIN ANALYZE screenshot for any new JOIN report query.

Outcome: Bad join order caught before merge to main.