maria-developers team mailing list archive

["Philip Stoev" <pstoev@xxxxxxxxxxxx>]

> > 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