← Back to team overview

maria-developers team mailing list archive

More MWL#89 questions

 

Hi Timour,

While merging, I also got the following questions:

== exclude_expensive_cond ==
make_cond_for_table()'s exclude_expensive_cond parameter is not used anymore.
Was it intentional that you kept it in the code? 
(minimizing MWL#89's diff size could not be a reason because the diff changes 
make_cond_for_table signature anyway)

== exec_const_cond ==
The patch introduces JOIN::exec_const_cond. On the other hand, the code 
already had JOIN::outer_ref_cond which seems to be nearly the same.

== join_tab_idx ==
make_join_select() attaches parts of WHERE/ON clauses to JOIN_TABs. It does
so with a help of two functions:
1. make_cond_for_table()
2. make_cond_after_sjm()
The first one does make set_join_tab_idx() calls, the second one doesn't. Why?


== join_tab_idx #2 ===

> @@ -7150,24 +7174,27 @@
>             there inside the triggers.
>        */
>        {            // Check const tables
> +        join->exec_const_cond=
> +   make_cond_for_table(thd, cond,
>                                join->const_table_map,
> -                              (table_map) 0, TRUE, FALSE);
> +                              (table_map) 0, MAX_TABLES, FALSE, FALSE);

As far as I understand the code, the MAX_TABLES part informs the constant 
subquery predicate that it will be evaluated  O(join_output_records) times, 
which is not true.

This is not the only such case, I see plenty of make_cond_for_table() calls
which use MAX_TABLES for join_tab_idx argument, where we can actually tell for
certain that the condition will be evaluated much fewer than 
O(join_output_records) times.

BR
 Sergey
-- 
Sergey Petrunia, Software Developer
Monty Program AB, http://askmonty.org
Blog: http://s.petrunia.net/blog


Follow ups