c50b3cfb3b
A 50k-file library used to wedge the database. This wave fixes the four reasons why, plus a timestamp-ordering bug the work exposed. Chunked scans (internal/library/scan.go) - One transaction wrapped the whole reconciliation, holding SQLite's single write lock for the entire scan. Now 500 groups per transaction, and the two missing-file passes are batched too. - Verified: a 20,000-file scan reports partial progress (scanned=1500 mid-scan) and a concurrent progress save returns 200 throughout. Under the old code that save blocked for the whole scan. - Behaviour change: a scan is no longer all-or-nothing. A crash now leaves a consistent partial scan. The scan is idempotent, so re-running finishes it. - res.Errors is capped at 100 (a broken mount used to append one string per file, then serialise the lot into the job row); the overflow is counted. Concurrent job workers (internal/jobs/jobs.go) - Run() was single-threaded, so a scan stalled every enrichment job behind it. Now 4 workers with jittered idle waits. - Handlers run concurrently, so Register/lookup take an RWMutex, and a panicking handler is recovered and marked failed rather than killing a worker and stranding a row in 'running'. - RecoverStale() requeues jobs left 'running' by a dead process; called at boot from main.go. Previously such a job stayed 'running' forever and the UI polled it forever. Explore (internal/media/discover.go) - Full-scanned and sorted the whole library on every home load, and was deterministic, so it showed the same 30 items every visit. Now a per-kind fair-share id range scan with a random start, wrap-around, dedup and interleaving. The doc comment claimed per-kind sampling before; now it does. Indexes (migrations/0008_query_indexes.sql) - Benchmarked with ANALYZE over 60k items: browse page 1 13.37ms -> 0.03ms (484x, full scan -> covering index), deep page 8x, recently added 3.2x. - A candidate index for the Continue shelf was built, measured and REJECTED: the planner never chose it because `finished = 0` selects the majority of a user's rows, so it had no selectivity and would have cost a write on every progress save. Recorded in the migration rather than shipped as dead weight. Canonical timestamps (internal/core/stamp.go) - time.RFC3339Nano trims trailing zeros, so its fraction width varies and the strings are not lexicographically sortable: ".5Z" > ".55Z" as strings though .500s < .550s. That broke every ORDER BY <timestamp> and MAX(timestamp), including the Continue shelf and Most Viewed. It was wrong even in columns written 100% by Go, so it was not a cross-format issue. - All 14 write sites now use core.Stamp, matching SQLite's own default format exactly. Read paths are untouched: RFC3339Nano parses both shapes, so existing rows keep working. Also: busy_timeout 5s -> 15s. Chunked scans still delay a concurrent write, and measured tail latency on a first scan of 15k new files reached 3.3s, leaving almost no margin at 5s. Waiting beats failing with SQLITE_BUSY and losing a playback position. A 10ms inter-batch yield was implemented, measured, found to have no effect distinguishable from noise (overlapping ranges), and removed. Verified end to end, not just compiled: orphan recovery logged at boot, scan returns 202 in 0.7ms, Explore varies across loads, concurrent writes survive a scan. gofmt/vet clean, 14 packages pass, -race clean on the queue, svelte-check 0/0, fresh install applies all 8 migrations.
25 lines
1.5 KiB
SQL
25 lines
1.5 KiB
SQL
-- 0008_query_indexes.sql — index the hot read paths.
|
|
--
|
|
-- These exist so the home screen and library browse are index-ordered instead
|
|
-- of sorting the whole library on every request. Each read path filters out
|
|
-- missing rows and orders on a column that had no supporting index, so SQLite
|
|
-- built and sorted the entire result set per page load. The column order below
|
|
-- mirrors the filter-then-sort shape of each query: the equality columns first,
|
|
-- then the ordering column, so the sort is satisfied by the index walk.
|
|
|
|
-- Browse: list a library's present items in display order.
|
|
CREATE INDEX idx_items_library_missing_sort ON media_items(library_id, missing, sort_title);
|
|
|
|
-- Home: "Recently added" and the suggestion shelves, newest first.
|
|
CREATE INDEX idx_items_library_missing_added ON media_items(library_id, missing, added_at DESC);
|
|
|
|
-- Explore: a per-kind id range scan wants kind and id together.
|
|
CREATE INDEX idx_items_kind_missing_id ON media_items(kind, missing, id);
|
|
|
|
-- Deliberately NOT indexed: the Continue shelf's `user_id + finished = 0` filter.
|
|
-- A candidate index on (user_id, finished, updated_at DESC) was built, benchmarked
|
|
-- against 30k progress rows with ANALYZE statistics, and never chosen — the query
|
|
-- planner prefers the primary-key autoindex, because `finished = 0` selects the
|
|
-- MAJORITY of a user's rows (people abandon more than they finish), so leading an
|
|
-- index with `finished` has almost no selectivity. It would cost a write on every
|
|
-- progress save, which happens every ~2s during playback, for no read benefit.
|