Last modified: 2011-05-15 10:05:52 UTC
Run CodeReview populateFollowupRevisions maintenance script on mediawiki wiki, so we can use the more efficient path searching :)
Could you run this on your local DB and report the table size and #rows before and after?
See https://bugzilla.wikimedia.org/show_bug.cgi?id=23720#c7 for rough figures Just re-ran it now after having updated to latest revisions mysql> select count(*) from mw_code_paths WHERE cp_repo_id = 3; +----------+ | count(*) | +----------+ | 1004172 | +----------+ 1 row in set (7.95 sec) Seems ~double number of paths
Is this normal behaviour? If so, what prevent us from running the script?
This is normal behaviour. The only thing sort of "preventing" us from us from running this, is the code not having been scapped live, allowing us to do somewhat more efficient SQL queries to do path searching, whereas before we're doing an SQL like which filesorts/temporary tables. Which isn't great. So this changes it so we save all path fragments, and can do an equals, rather than like and other crappy stuff So this goes through and repopulates the path list, to list all fragments as a separate row per path fragment for a revision commited
Bah. So this bug exists as basically a TODO/reminder for Roan :)
per IRC, this is pending script deployment on live site. Assigning to Roan
Noted as a scaptrap https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/79379#c13295 I'll need to do this some time before deployment, I guess.
Should this depend on the 1.17 deployment? Or is this another deployment?
(In reply to comment #8) > Should this depend on the 1.17 deployment? Or is this another deployment? 1.17, yes.
(In reply to comment #9) > (In reply to comment #8) > > Should this depend on the 1.17 deployment? Or is this another deployment? > 1.17, yes. ...although I guess it wouldn't hurt to do this earlier and get it out of the way.
It will obviously need a followup run later on, just to fully update the newer revs, but that really is a minor issue, and we can choose a rev list, so its not a big deal ;)
(In reply to comment #9) > (In reply to comment #8) > > Should this depend on the 1.17 deployment? Or is this another deployment? > 1.17, yes. Are you going to push all the cr revisions post 1.17 into the 1.17 branch? As I'm sure this was post branching... And of course it needs running for all repositorys
(In reply to comment #12) > (In reply to comment #9) > > (In reply to comment #8) > > > Should this depend on the 1.17 deployment? Or is this another deployment? > > 1.17, yes. > > Are you going to push all the cr revisions post 1.17 into the 1.17 branch? > > As I'm sure this was post branching... > > And of course it needs running for all repositorys It's post-branch? Awesome! Then I won't have to worry about it for another few weeks.
Looks like I did it 3 weeks or so later post branch
Done
