A page of items reads every enclosure in the database to find its files #344
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
entries_where (crates/ipx/src/db.rs, the enclosures lookup after the page's rows) asks for enclosures by guid alone. The only index is enclosures_entry (feed_id, guid), so Postgres reads the whole index, 587k rows: EXPLAIN ANALYZE on production, the 50 newest of user 2's items, 250 ms and 9,150 buffers. With feed_id IN (the page's feeds) as well, 0.5 ms. Every /api/entries, /api/feeds/{id}/entries, Signal page and single entry goes through it; /api/entries has 1.3 s outliers inside entries_in (trace 4c6d917cccfed5293e813cc03d9a64e7). Found looking over traces for optimizations.
Fixed in
aa430f6: the enclosure lookup adds feed_id IN (the page's feeds), so it uses enclosures_entry (feed_id, guid). Deployed; /api/entries?limit=50 answers in 37-52 ms on production.