https://bugzilla.wikimedia.org/show_bug.cgi?id=43287
--- Comment #8 from Richard Guk <[email protected]> --- (In reply to comment #7) > One of reasons this number was considered misleading was that for performance > reasons queue size is estimated, not counted. And these estimations can be > wildly inaccurate. This will remain an issue at least as long as the queue is > kept in MySQL. Understood (per bug 27584). I only mentioned the Special:Statistics removal in response to reedy's aside. The API jobs value seems to oscillate disconcertingly between 3 disparate values at any one time (presumably because of aggressive caching), but that oddity is outside the scope of this request. Focusing again on reporting the queue duration: The proposed information would be easy to calculate accurately, as well as being more useful to know than the queue size. Even if value caching were needed (doubtful), the value would only need refreshing each time an oldest job were run. But the minimum value of an indexed field is already perfectly optimised for a database lookup. When this enhancement was previously requested (bug 13786, which I have only just found), it was rejected because the job_timestamp column did not exist at the time. So the main hurdle has already been overcome. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
