f275de5c8f
v_feed computed like_count/comment_count with LEFT JOINs and a GROUP BY. Postgres CAN push `event_id = $1` and the keyset predicate through the view — verified with EXPLAIN, it uses idx_upload_event_created_id — but it CANNOT push ORDER BY ... LIMIT across a GroupAggregate. So every request aggregated every upload in the event, times its likes and comments, and only then sorted and took 21 rows. Cost grew with the event, not with the page. Measured on a throwaway database seeded to a real reception (1000 uploads, 100 guests, 27k likes, 10k comments), same query, same data: before GroupAggregate (actual rows=1001) -> Sort -> Limit 449 ms after Index Scan (actual rows=21) -> Limit -> SubPlans 0.58 ms migration 022 replaces the joins with correlated scalar subqueries, which puts the counts ABOVE the Limit so they run 21 times instead of 1001. Exactly equivalent, not merely close: "like" is keyed (upload_id, user_id) so COUNT(DISTINCT user_id) == count(*), comment.id is the PK so COUNT(DISTINCT c.id) == count(*), and the GROUP BY was on u.id so it was already one row per upload. Column names, order and types are unchanged, so no Rust changes. No new index needed — idx_like_upload and idx_comment_upload already match the subqueries. Note the existing load harness cannot see any of this: e2e/loadtest/driver.mjs creates no likes and no comments, so the expensive path had never been exercised. The amplifier, feed/+page.svelte: every open feed subscribed to `upload-processed` and refetched page 1 — the most expensive page — so ~100 open feeds each fired one per completed upload. Now gated on whether this client actually shows the card that changed, and the debounce is jittered, because a fixed delay just moves a simultaneous herd 800 ms later. Nothing is lost by skipping: a client without the card also missed its `new-upload`, and the reconnect `feed-delta` already schedules a refresh. Load shedding, because the above reduces the risk rather than removing it: db.rs set no acquire_timeout, so sqlx's 30 s default applied — longer than the frontend's own 20 s fetch timeout, meaning the browser gave up while the server kept holding the slot and the work was done for nobody. Now 5 s, and PoolTimedOut maps to 503 + Retry-After instead of a generic 500. That mattered because the upload queue classifies 5xx as transient and retries: a 500 sent the retries straight back into the saturated pool with nothing to pace them. PoolClosed stays Internal — it only occurs during shutdown, where a 503 would invite a retry against a server that is going away. The Retry-After extraction in into_response matches on variants, so unlike message() a missing arm is not a compile error — it would silently drop the header. Pinned by a test covering both retry-carrying variants. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
27 lines
759 B
SQL
27 lines
759 B
SQL
-- Restore the 016 definition verbatim.
|
|
DROP VIEW IF EXISTS v_feed;
|
|
CREATE VIEW v_feed AS
|
|
SELECT
|
|
u.id,
|
|
u.event_id,
|
|
u.user_id,
|
|
usr.display_name AS uploader_name,
|
|
usr.is_banned,
|
|
usr.uploads_hidden,
|
|
u.preview_path,
|
|
u.thumbnail_path,
|
|
u.display_path,
|
|
u.mime_type,
|
|
u.caption,
|
|
u.created_at,
|
|
COUNT(DISTINCT l.user_id) AS like_count,
|
|
COUNT(DISTINCT c.id) AS comment_count
|
|
FROM upload u
|
|
JOIN "user" usr ON u.user_id = usr.id
|
|
LEFT JOIN "like" l ON l.upload_id = u.id
|
|
LEFT JOIN comment c ON c.upload_id = u.id AND c.deleted_at IS NULL
|
|
WHERE u.deleted_at IS NULL
|
|
AND usr.uploads_hidden = FALSE
|
|
AND usr.is_banned = FALSE
|
|
GROUP BY u.id, usr.display_name, usr.is_banned, usr.uploads_hidden;
|