mirror of
https://github.com/navidrome/navidrome.git
synced 2026-10-08 10:27:08 +02:00
dbd26ba2e7* perf(persistence): avoid a full media_file scan when resolving playlist paths FindByPaths built one OR-ed equality term per path. On the real media_file schema SQLite abandons the path index at just two OR-ed terms and falls back to SCAN media_file, re-testing every term against every row, so the cost grows with (rows x terms). Group the candidates by library and emit one IN list per library instead, which plans as SEARCH media_file USING INDEX media_file_path_nocase. The NOCASE collation is kept so ASCII case-insensitive matching still works. This is the dominant cost of M3U playlist import, which resolves every track on every scan. Measured with a 1000-track playlist against a migrated DB: 100k media_file rows: 397 -> 51,414 tracks/sec 500k media_file rows: 78.5 -> 47,174 tracks/sec The rate no longer degrades as the table grows, which is the expected shape for an index lookup. Reported in #6043, where an 8 hour scan of a 2M-song library spent 7h52m in the playlist phase. * docs(playlists): correct the stale reason for the M3U lookup chunk size The expression-tree depth ceiling applied to the old OR-per-path query, which capped a batch at roughly 500 terms. The IN form is bound by SQLite's 32766 variable limit instead, which the 400 candidates per chunk sit far below. |
||
|---|---|---|
| .. | ||
| agents | ||
| artwork | ||
| auth | ||
| external | ||
| ffmpeg | ||
| lyrics | ||
| matcher | ||
| metrics | ||
| playback | ||
| playlists | ||
| publicurl | ||
| scrobbler | ||
| sonic | ||
| storage | ||
| stream | ||
| archiver.go | ||
| archiver_test.go | ||
| common.go | ||
| common_test.go | ||
| core_suite_test.go | ||
| inspect.go | ||
| library.go | ||
| library_test.go | ||
| maintenance.go | ||
| maintenance_test.go | ||
| players.go | ||
| players_test.go | ||
| share.go | ||
| share_test.go | ||
| user.go | ||
| user_test.go | ||
| wire_providers.go | ||