The feed list counts every item of every feed on each load #240
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?
GET /api/feeds' feed_list step 'entries' counts all stored items per subscribed feed on every request: 366 of 465 ms in trace cb6b7fcf86ba11699f00f74cf030565b (2026-10-15). The count is the same for everyone and changes only when items are stored or pruned.
Left open, waiting on #241: on the load test's Postgres, scaled to production's shape (150,000 items, 147 feeds of ~100), this count takes 12 ms (index-only scan) and All Subscriptions 32 ms, against 366 and 300 ms in production. The query is not the problem; production's database is. A cache here would be rebuilt after nearly every scan anyway, since scans store items every few minutes.
Closed with #241's fix, not a cache: on production this count takes 5 ms in Postgres; its 366 ms in the trace was waiting for a new connection, which the daemon now keeps open. A cache would have been rebuilt after nearly every scan.