Bereitschaftsabschnitt führt bei einem bestimmten Moderator zu einem 500-Serverfehler

zogstrip · 12. Oktober 2026 um 20:52

Ich habe einen Weg gefunden, die Abfrage zu optimieren, ohne den OFFSET 0-Trick zu verwenden

github.com/discourse/discourse

PERF: Check review queue visibility per topic for moderators (#44497)

main ← perf/review-queue-moderator-visibility

merged 08:26AM - 13 Oct 26 UTC

ZogStriP

+95 -30

Previously, the review queue built every visible topic and every private message… a moderator can see as whole-table subqueries (`topic_id IN (...)` and `NOT IN (...)`). On large sites, Postgres scanned millions of posts or rescanned the PM list once per reviewable. `/review` then timed out with a 500 for non-admin moderators (https://meta.discourse.org/t/414526). This change correlates those checks to each reviewable's topic with `EXISTS` / `NOT EXISTS`, so Postgres does index lookups per reviewable, with the same visibility rules. On a 1M topic / 8M post dataset, the count + page queries for a moderator drop from ~10–32s to ~0.5s, and the pending count from ~4.5s to ~50ms.

Thema		Antworten	Aufrufe
Category Moderators may receive incorrect number of pending reviews Bug category-moderators , review-queue	0	83	7. August 2026
Feedback on the new Review Queue (2019) Announcements new-feature , review-queue	260	21110	11. März 2023
Proposal: Consolidated Review Queue Feature	33	6378	28. März 2019
A new review queue layout with all new features Announcements review-queue	43	3014	20. September 2026
App/models/topic_tracking_state - `report` - long response times? Development slow-sql	6	1932	26. Februar 2016

Bereitschaftsabschnitt führt bei einem bestimmten Moderator zu einem 500-Serverfehler

Verwandte Themen