Follow-up to #86 (mailbox message-loading performance). PR #123 made the per-account+folder list flat (~80x faster at 20k rows) by scoping the query in SQL. But the unified "All inboxes" view (WHERE folder = ?, no accountId) has no leading index, so it remains an O(N) scan and materializes the entire unified inbox (~3.7k rows at a 20k-row cache) into memory.
Scope
Apply Room Paging3 / PagingSource to the unified-inbox list path so both query cost and recomposition scale with what's on screen, not the whole unified inbox.
Evaluate via EXPLAIN QUERY PLAN whether a (folder, timestampMillis) index is warranted. Note from #86: the accountId-leading composite index does NOT help this path. Prefer Paging3 with the existing indices (no schema change) if it captures the win; only add an index if measurably necessary.
If (and only if) an index is added, it's a schema migration — coordinate the DB version with the in-flight PR #118 (which also bumps the schema and is under maintainer review).
Leave the per-account+folder path from #123 unchanged (already flat).
Acceptance
Unified-inbox query/scroll cost scales with the visible page, not total cache, verified against a large (multi-thousand-row) seeded cache with a before/after measurement.
No regression to per-account views.
Origin: profiling report docs/perf/issue-86-profiling.md (added in #123).
Follow-up to #86 (mailbox message-loading performance). PR #123 made the per-account+folder list flat (~80x faster at 20k rows) by scoping the query in SQL. But the unified **"All inboxes"** view (`WHERE folder = ?`, no `accountId`) has no leading index, so it remains an **O(N) scan** and materializes the entire unified inbox (~3.7k rows at a 20k-row cache) into memory.
## Scope
- Apply Room `Paging3` / `PagingSource` to the unified-inbox list path so both query cost and recomposition scale with what's on screen, not the whole unified inbox.
- Evaluate via `EXPLAIN QUERY PLAN` whether a `(folder, timestampMillis)` index is warranted. **Note from #86: the `accountId`-leading composite index does NOT help this path.** Prefer Paging3 with the existing indices (no schema change) if it captures the win; only add an index if measurably necessary.
- If (and only if) an index is added, it's a schema migration — coordinate the DB version with the in-flight PR #118 (which also bumps the schema and is under maintainer review).
- Leave the per-account+folder path from #123 unchanged (already flat).
## Acceptance
- Unified-inbox query/scroll cost scales with the visible page, not total cache, verified against a large (multi-thousand-row) seeded cache with a before/after measurement.
- No regression to per-account views.
Origin: profiling report `docs/perf/issue-86-profiling.md` (added in #123).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Follow-up to #86 (mailbox message-loading performance). PR #123 made the per-account+folder list flat (~80x faster at 20k rows) by scoping the query in SQL. But the unified "All inboxes" view (
WHERE folder = ?, noaccountId) has no leading index, so it remains an O(N) scan and materializes the entire unified inbox (~3.7k rows at a 20k-row cache) into memory.Scope
Paging3/PagingSourceto the unified-inbox list path so both query cost and recomposition scale with what's on screen, not the whole unified inbox.EXPLAIN QUERY PLANwhether a(folder, timestampMillis)index is warranted. Note from #86: theaccountId-leading composite index does NOT help this path. Prefer Paging3 with the existing indices (no schema change) if it captures the win; only add an index if measurably necessary.Acceptance
Origin: profiling report
docs/perf/issue-86-profiling.md(added in #123).