To find changes relevant to wiki x, we should be able to join wb_changes against wb_changes_subscriptions. This would remove the need for programmatic filtering.
- Mentioned In
- T193733: Move dispatching of wikidata to a dedicated node
T111161: Subscribe client wikis immediately after adding sitelinks
T171263: Wikidata Dispatcher and Job Queue is overflowed
T118162: Wikibase dispatchChanges.php runs slow, creates an absurd amount of database connections
T112245: [Task] Configure wikidata.org to rely on the wb_changes_subscription table for dispatching.
T108944: [Epic] Improve change dispatching
T109088: [Task] Profiling and investigate how to improve performance of change dispatcher
- Mentioned Here
- T111161: Subscribe client wikis immediately after adding sitelinks
T109825: [Task] Use uppercase entity ID in wb_changes table.
Rising priority: Dispatching is an ongoing problem and this will fix (most of?) this.
Also I guess the number of changes that actually need dispatching has decreased (as we have a lot of entities not used on any sister project) these days. Thus fixing this and increasing the job batch size (or completely changing how that works) would fix the dispatching bottleneck for now.