On Sun, Aug 1, 2010 at 5:03 PM, Roan Kattouw <roan.katt...@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 <platoni...@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. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
