On Sun, Aug 1, 2010 at 5:03 PM, Roan Kattouw <roan.kattouw(a)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(a)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.