| Thread Previous • Date Previous • Date Next • Thread Next |
REQUEST: I'm not exactly sure what to do with@@debug_optimizer_prefer_join_prefix, we both should think about how to use it (take a query, and try forcing all possible join orders?). At least, it shouldbe easier to repeat the bugs now.
Elena,The reason I asked for this feature is because the RQG detected some transient semijoin issues that were not repeatable outside of the RQG. In particular, the RQG reported seeing EXPLAIN plans where "End Temporary" was before "Start Temporary", which should never happen. Sergey P reported that it is difficult to build an assertion for this situation that will make the server crash, so the only option is to find a repeatable MTR test case.
However, STRAIGHT JOIN and FORCE INDEX are not enough to force a particular ordering of tables where semijoin is involved, as semijoin may place the tables from the subquery anywhere in the join order of the outer query. Hence the idea to force an order using a separate variable.
The way to use this feature is to create a new Validator for the RQG that will
1. Run explain to obtain the names of participating tables2. Use Bernt's code from combinations.pl --run-all-combinations-once to generate each possible join order, or at least move around just the semijoined tables; 3. Let the RQG execute the modified query and compare the result to the original join order
This can be accomplished with a short Perl module, which would be a nice exercise in RQG internals. Let me know if you want to do it and I will help sort out the technicalities.
Philip Stoev
BR Sergei -- Sergei Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@xxxxxxxxxxxxxxxxxxx Unsubscribe : https://launchpad.net/~maria-developersMore help : https://help.launchpad.net/ListHelp
| Thread Previous • Date Previous • Date Next • Thread Next |
