Unread lists and counts read all of a person's items to find the few unread #347
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?
All Subscriptions' Unread page and its count each read every item of the person's feeds (11,703 for user 2) and hash all their entry_state rows (22,918) to find 32 unread: 29 ms and 24 ms on production (EXPLAIN ANALYZE). feed_list's unread count does the same. It grows with the back catalogue. Left for now; a partial index on unread state or kept counts would make it start from the few.
Fixed in
a11e3b6: subscriptions.unread_from marks where each person's unread begins in each feed; unread lists, their counts and the feed list's unread counts join it (index entries_seen on (feed_id, first_seen)). The reap job and daemon start move it up to the oldest unread item (never past an hour ago), and marking an item unread clears it, so it can only be stale, never wrong. Deployed; production lists the same 44 unread as before, and All Subscriptions' unread count (EXPLAIN ANALYZE, user 2) reads 213 items instead of 11,727: 19 ms, was 27-32. What is left of the 19 ms is filed as a new issue.