Uh oh!
There was an error while loading. Please reload this page.
perf(db): add missing hot-path indexes (#160, #161, #176, #177, #178) - #244
perf(db): add missing hot-path indexes (#160, #161, #176, #177, #178)#244Jose-Gael-Cruz-Lopez wants to merge 24 commits into
Conversation
Deploying with |
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ❌ Deployment failed View logs | frontend | 28ae402 | Jun 22 2026, 03:52 AM |
Warning Review limit reached
More reviews will be available in 47 minutes and 35 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
The hand-applied migration ran plain CREATE INDEX, which takes an ACCESS EXCLUSIVE lock on each table for the whole build and would stall live traffic on hot tables (messages, sessions, graph_edges, documents). Switch every statement to CREATE INDEX CONCURRENTLY IF NOT EXISTS and document the non-transactional / INVALID-index recovery caveats. The canonical schema keeps plain CREATE INDEX since it runs on empty tables.
idx_graph_edges_source/target are single-column rather than composite with user_id on purpose: the bulk dedup deletes in db/dedup_nodes.py filter the endpoint via in.(...) without user_id, which a leading-user_id composite could not serve. Note the rationale in the schema.
The drift guard only checked that each table name appeared somewhere in the migration, which a comment mention would satisfy. Match the index name followed by an ON <table>( clause instead so a misdirected index is caught.
Deploying with |
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs | frontend-staging | 4d1e6a1 | Commit Preview URL Branch Preview URL | Jun 24 2026, 02:48 PM |
The flat db/migration_perf_indexes.sql predates main's ordered migrations/ layout (run by db/migrate.py) and was never picked up by the runner. Replace it with a numbered, idempotent migration so existing databases (baselined before these indexes existed) get them. Fresh DBs already get them via 0001_baseline_schema.sql. Uses plain CREATE INDEX IF NOT EXISTS instead of CONCURRENTLY because migrate.py applies each migration inside a transaction block.
The test read supabase_schema.sql and migration_perf_indexes.sql, both gone after main restructured db files. Read the canonical locations that exist now: 0001_baseline_schema.sql (fresh DBs) and 0019_perf_indexes.sql (existing DBs), keeping the on-table + idempotency assertions.
Adds the ten missing indexes called out in the backend performance audit. Every query site listed below currently full-scans + sorts the target table on the critical path.
Indexes added
messages(session_id, created_at)— chat-history load (fastest-growing table)graph_edges(user_id),(source_node_id),(target_node_id)— graph render + cascade deletesessions(user_id, started_at DESC)— history list + profile statsdocuments(user_id, created_at DESC),(user_id, course_id)— library list + study-guide contextstudy_guides(user_id, generated_at DESC),(user_id, course_id, exam_id)— guide list + cache lookupquiz_attempts(user_id)— achievement counts + history aggregationsChanges
backend/db/migration_perf_indexes.sql— new hand-applied migration (allCREATE INDEX IF NOT EXISTS, re-runnable).backend/db/supabase_schema.sql— same indexes mirrored so fresh environments match prod.backend/tests/test_perf_indexes_present.py— drift guard asserting each index lives in both files and isIF NOT EXISTS-guarded.Verification
ruff check .clean; full gated suite green (685 + 3 new).EXPLAINconfirmation is left to a reviewer with DB access; index column orders match the documented query filters/sorts.Closes#160, #161, #176, #177, #178.