The tree is in launchpad and buildbot also: https://code.launchpad.net/~maria-captains/maria/5.3-dsmrr-cpk
and all observed buildbot failures in the tree are known to occur without the new code as well.
The above mentioned tree has DS-MRR improvements that are ready for testing.
Hi, thanks for the tree. I have already started testing it and filing bugs for you.
Checking if new code is used ---------------------------- Execution passes through the new code if the EXPLAIN has tables that have type=[eq_]ref, Extra has 'Using join buffer'.
I am afraid it is not sufficient to properly figure out which optimization causes which issue, especially after your code is merged into the main tree. It is very important that each 5.3 optimization has its own distinct comment in the "Extra" field (or at the very least, in EXPLAIN EXTENDED). Can you hack that quickly today or tomorrow?
- Run the query with bigger/smaller value of @@join_buffer_size (this is where I've found and fixed a big number of problems already). - where the join buffer is exhausted at various stages of accessing table t1 (need to try with different key sizes, join buffer sizes, and many-table joins)
What values would you suggest? Currently I am running with join_buffer_size={1,100,1K,10K,100K} . There are 3 to 5 tables per query, with 1 to 1000 rows per table. Unfortunately, I am hitting quite a few MRR/DSS/BKA bugs that are also present in maria-5.3 Some of them have been filed in the past in the MySQL tracker and some have been fixed by the MySQL guys. Others however appear to not be known, since BKA testing was never completed back in the day. So, how are we going to handle this? Essentially you have created new optimizations on top of a foundation that is still buggy and unstable from the 6.0-codebase days. Who and when will be able to fix the foundation and make it stable? Philip Stoev