maria-developers team mailing list archive

[Oleksandr Byelkin <sanja@xxxxxxxxxxxx>]

Hi!

Everything looks OK, except one small style error.

Also it would be nice to put somewhere 'TODO:' to bring in order 
'uncachable' flags.

On 03.03.2011 14:07, timour@xxxxxxxxxxxx wrote:
> At file:///home/tsk/mprog/src/5.3/
>
> ------------------------------------------------------------
> revno: 2929
> revision-id: timour@xxxxxxxxxxxx-20110303120726-la5o40rldim2t93y
> parent: psergey@xxxxxxxxxxxx-20110301072222-1rmapkelx9l1kw8u
> committer: timour@xxxxxxxxxxxx
> branch nick: 5.3
> timestamp: Thu 2011-03-03 14:07:26 +0200
> message:
>    Fix LP BUG#718763
>
>    Analysis:
>    The reason for the crash was that the inner subquery was executed
>    via a scan on a final temporary table applied after all other
>    operations. This final operation is implemented by changing the
>    contents of the JOIN object of the subquery to represent a table
>    scan over the temp table. At the same time query optimization of
>    the outer subquery required evaluation of the inner subquery, which
>    happened before the actual EXPLAIN. The evaluation left the JOIN
>    object of the inner subquery in the changed state, where it represented
>    a table scan over a temp table, and EXPLAIN crashed because the temp
>    table is not associated with any table reference (TABLE_LIST object).
>    The reason the JOIN was not restored was because its saving/restoration
>    was controlled by the join->select_lex->uncacheable flag, which was
>    not set in the case of materialization.
>
>    Solution:
>    In the methods Item_in_subselect::[single | row]_value_transformer() set:
>        select_lex->uncacheable|= UNCACHEABLE_EXPLAIN;
>    In addition, for symmetry, change:
>        master_unit->uncacheable|= UNCACHEABLE_EXPLAIN;
>    instead of UNCACHEABLE_DEPENDENT because if a subquery was not
>    dependent initially, the changed methods do not change this
>    fact. The subquery may later become correlated if it is transformed
>    to an EXISTS query, but it may stay uncorrelated if executed via
>    materialization.
[skip]
> @@ -1742,7 +1752,15 @@ Item_in_subselect::row_value_transformer
>       optimizer->keep_top_level_cache();
>
>       thd->lex->current_select= current;
> -    master_unit->uncacheable|= UNCACHEABLE_DEPENDENT;
> +    /*
> +      The uncacheable property controls a number of actions, e.g. whether to
> +      save/restore (via init_save_join_tab/restore_tmp) the original JOIN for
> +      plans with a temp table where the original JOIN was overriden by
> +      make_simple_join. The UNCACHEABLE_EXPLAIN is ignored by EXPLAIN, thus
> +      non-correlated subqueries will not appear as such to EXPLAIN.
> +    */
> +    master_unit->uncacheable|=UNCACHEABLE_EXPLAIN;
> +    select_lex->uncacheable|= UNCACHEABLE_EXPLAIN;
>
>       if (!abort_on_null&&  left_expr->maybe_null&&  !pushed_cond_guards)
>       {

put space (' ') after '='

[skip]
> _______________________________________________
> commits mailing list
> commits@xxxxxxxxxxx
> https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits