Gregory,
thanks for the warning. The toolserver will not work for
this - its using MySQL 5, which optimizes everything very differently.
Plus it is using views instead of tables - again, there are some
optimization bugs associated with that. This really has to be on the
main wiki - this way we could even compare a large wiki vs a small
wiki query optimizations.
It probably wouldn't be a huge security risk to open up a slave to
this, but I don't expect it to happen anytime soon.
I guess we can make a list of prohibited
fields/tables.
The only feasible option.
What if there was a standalone MySQL ~4.0.29 database somewhere that had
loaded an Enwiki pages-meta-history.xml database dump, and which allowed
people to run EXPLAIN queries on it via a web interface - wouldn't that mostly
solve the problem?
By definition, we know/assume that the dumps do not contain confidential
information - so rather than trying to enumerate data that needs protection,
this way there is simply no sensitive data there in the first place to protect.
And in the web interface for running the EXPLAIN queries, there could also be
a big "RESET" button that would copy over backups of the MySQL data files, thus
resetting the database back to a known state if it became messed up somehow.
Disclaimer: I don't personally feel any desire to build such a thing, I'm just
trying to understand whether it would solve the problem or not.
-- All the best,
Nick.