-- 0013: index journal_entries on (company_id, entry_date) — review finding
-- on Task 3 of docs/superpowers/plans/2026-08-01-bank-rec.md. Forward-only;
-- 0002-0012 are already applied everywhere (including the dev DB, which has
-- real customer data), so this is a plain CREATE INDEX, never an edit to an
-- earlier file.
--
-- journal_entries had no index at all on entry_date before this — only the
-- composite PRIMARY KEY (id) and UNIQUE (company_id, id) from 0002. Every
-- date-range query against this table (per company) was a sequential scan
-- filtered afterward. The bank-rec matching engine
-- (server/src/lib/statementMatch.ts's findCandidateEntries) is the query
-- that surfaced this concretely: it runs once PER STATEMENT LINE, filtering
-- journal_entries by company_id and an entry_date BETWEEN window (when
-- called with withinDays), so on an account with a few thousand posted
-- entries it was rescanning the company's ENTIRE journal_entries history for
-- every single line of every imported statement — O(statement lines x
-- ledger history) forever, not just a slow first run.
--
-- This index benefits far more than the matching engine — every report and
-- aging function that filters journal_entries by company_id and a date
-- range (trial_balance, ar_aging/ap_aging's underlying entry lookups, the
-- accounts drill-through in reports.ts, journal-load.ts's per-year batch
-- checks) gets the same plan improvement, which is why it's a plain
-- (company_id, entry_date) btree rather than something narrower scoped only
-- to the bank-rec query shape.

CREATE INDEX journal_entries_by_company_date ON journal_entries (company_id, entry_date);
