On Sun, Aug 1, 2010 at 5:03 PM, Roan Kattouw roan.kattouw@gmail.com wrote:
I don't know. Cursory inspection seems to indicate user_properties is relatively complete, but comprehensive count queries are too slow for me to dare run them on the cluster. Maybe you could run something along the lines of SELECT COUNT(DISTINCT up_user) FROM user_properties; on the toolserver and compare it with SELECT COUNT(*) FROM user;
That won't work, because it won't count users whose settings are all default. However, we can tell who's switched because user_options will be empty.
On Sun, Aug 1, 2010 at 5:48 PM, Platonides Platonides@gmail.com wrote:
Note that we do offer several options, not only the free-text field. I think that the underlying problem is that when changing an article from 98 bytes to 102, we would need to invalidate all pages linking to it for stubthresholds of 100 bytes.
Aha, that must be it. Any stub threshold would require extra page invalidation, which we don't do because it would be pointlessly expensive. Postprocessing would fix the problem.
Since the pages are reparsed, custom values are not a problem now. I think that to cache for the stubthresholds, we would need to cache just before the replaceLinkHolders() and perform the replacement at the user request.
Yep. Or parse further, but leave markers lingering in the output somehow. We don't need to cache the actual wikitext, either way. We just need to cache at some point after all the heavy lifting has been done, and everything that's left can be done in a couple of milliseconds.