Three independent refactors of lib/music_library/listening_stats.ex,
measured against the dev DB (104k tracks) via bench/listening_stats.exs:
| Query | Baseline | After | Speedup |
|---------------------------------|-----------|-----------|---------|
| recent_activity(tz, 100) | 38.98 ms | 2.87 ms | 13.6x |
| list_tracks(page 1, 200) | 47.30 ms | 4.81 ms | 9.8x |
| get_top_artists_by_days(7) | 66.51 ms | 1.02 ms | 65x |
| get_top_artists_by_days(30) | 67.41 ms | 2.84 ms | 23.7x |
| get_top_artists_by_days(365) | 76.03 ms | 25.57 ms | 3.0x |
| get_top_albums_by_days(7) | 92.63 ms | 1.61 ms | 57.5x |
| get_top_albums_by_days(30) | 94.52 ms | 3.69 ms | 25.6x |
| get_top_albums_by_days(365) | 105.23 ms | 32.81 ms | 3.2x |
| get_top_artists(limit: 10) | 123.96 ms | 101.68 ms | 1.22x |
| get_top_albums(limit: 10) | 209.64 ms | 108.23 ms | 1.94x |
tracks_with_record_info_query/0 now uses correlated scalar subqueries
against record_releases and artist_records instead of materializing
helper subqueries on every call. The cost scales with the outer LIMIT,
not with the size of record_releases.
top_albums_base_query/0 and top_artists_base_query/0 are replaced by
aggregate_query + attach_metadata pairs. The pattern is aggregate first,
attach metadata second: GROUP BY runs against the raw track scan, then
a tiny outer SELECT attaches record_releases / artist_infos lookups for
the <= 10 result rows via correlated subqueries.
tracks_since_query/1 wraps the date-filtered inner scan with limit: -1.
SQLite cannot flatten a subquery that has a LIMIT, so it materializes
the date-bounded subset and the optimizer uses the timestamp index for
the range scan instead of the album/artist composite index. This trick
replaces SQLite's WITH ... AS MATERIALIZED (which ecto_sqlite3 doesn't
expose).
All json_extract(?, '\$.path') fragments use the canonical form rather
than the equivalent ? ->> '\$.path' shorthand. SQLite's index matcher
requires the GROUP BY expression to match the index expression
textually to use the composite index for natural ordering.
collected_releases_query/0 and wishlisted_releases_query/0 are removed
from Collection and Wishlist — they had a single internal caller that
no longer exists after the refactor.
New regression tests lock the semantics that the optimized queries
must preserve:
- count(DISTINCT scrobbled_at_uts) — 579 duplicate timestamps exist in
the dev DB from rapid Last.fm scrobbles, so replacing with count(*)
would silently change results
- :artist_id key in list_tracks result maps — ScrobbledTracksLive.Index
destructures it even though the template body never references it
Closes#148
Ecto telemetry reporter that captures executed SQL queries
to a log file with interpolated parameters and source
locations. Activated/deactivated at runtime via Tidewave
for LLM-driven query analysis workflows.
Replace "always provide a link" with conditional linking and add
instructions to vary response style and avoid restating information
already covered in the conversation.
Co-authored-by: Claude <noreply@anthropic.com>
When barcode scan results contain at least 2 new records,
enqueue individual Oban jobs instead of importing synchronously.
Wishlisted/collected/not_found results still process synchronously.
Includes a around embedding generation, which was happening twice (the
first call was redundant as record embeddings are always regenerated
after their parent artist embeddings are regenerated).
Closes#144.
Claudio Ortolina