Commit graph

12 commits

Author SHA1 Message Date
unknown
ea8aa32909 Fix for bug lp:834492
Analysis:
In the test query semi-join merges the inner-most subquery
into the outer subquery, and the optimization of the merged
subquery finds some new index access methods. Later the
IN-EXISTS transformation is applied to the unmerged subquery.
Since the optimizer is instructed to not consider
materialization, it reoptimizes the plan in-place to take into
account the new IN-EXISTS conditions. Just before reoptimization
JOIN::choose_subquery_plan resets the query plan, which also
resets the access methods found during the semi-join merge.
Then reoptimization discovers there are no new access methods,
but it leaves the query plan in its reset state. Later semi-join
crashes because it assumes these access methods are present.

Solution:
When reoptimizing in-place, reset the query plan only after new
access methods were discovered. If no new access methods were
discovered, leave the current plan as it was.
2011-09-01 23:53:12 +03:00
Igor Babaev
2092436457 Merge. 2011-07-21 15:55:08 -07:00
Igor Babaev
63abf00a62 Made the optimizer switches 'derived_merge' and 'derived_with_keys'
off by default.
2011-07-21 14:23:08 -07:00
unknown
ef2b4b14e1 Merge from 5.2 2011-07-21 15:50:25 +03:00
unknown
af284b55f0 Make subquery cache off by default.
mysql-test/r/subselect_scache.result:
  Test with subquery cache on.
mysql-test/t/subselect_scache.test:
  Test with subquery cache on.
2011-07-15 11:36:36 +03:00
Igor Babaev
a853c7dd18 Merge. 2011-06-28 19:56:30 -07:00
unknown
78fa331eaa Fixed bug lp:800679
Analysis:
  The failed assert ensured that the choice of subquery strategy
  is performed only for queries with at least one table. If there
  is a LIMIT 0 clause all tables are removed, and the subquery is
  neither optimized, nor executed during actual optimization. However,
  if the query is EXPLAIN-ed, the EXPLAIN execution path doesn't remove
  the query tables if there is a LIMIT 0 clause. As a result, the
  subquery optimization code is called, which violates the ASSERT
  condition.
  
Solution:
  Transform the assert into a condition, and if the outer query
  has no tables assume that there will be at most one subquery
  execution.
  
  There is potentially a better solution by reengineering the
  EXPLAIN/optimize code, so that subquery optimization is not
  done if not needed. Such a solution would be a lot bigger and
  more complex than a bug fix.
2011-06-28 15:48:44 +03:00
Igor Babaev
f03a3ee54f Merged the code of mwl 106 into the latest 5.3 with mwl 90 pushed.
Resolved all conflicts and failures.
2011-06-04 19:56:06 -07:00
unknown
742dfc92a2 MWL#89: Address review feedback (by Sergey Petrunia)
mysql-test/r/subselect4.result:
  Moved test case for LP BUG#718593 into the correct test file subselect_mat_cost_bugs.test.
mysql-test/t/subselect4.test:
  Moved test case for LP BUG#718593 into the correct test file subselect_mat_cost_bugs.test.
2011-05-23 10:56:05 +03:00
Igor Babaev
704f97035f Merged the code of MWL#106 into 5.3
Resolved all conflicts, bad merges and fixed a few minor bugs in the code.
Commented out the queries from multi_update, view, subselect_sj, func_str,
derived_view, view_grant that failed either with crashes in ps-protocol or
with wrong results.
The failures are clear indications of some bugs in the code and these bugs
are to be fixed.
2011-05-16 22:39:43 -07:00
unknown
0f4236659c Fix LP BUG#718593
Analysis:
Build_equal_items_for_cond() rewrites the WHERE clause in such a way,
that it may merge the list join->cond_equal->current_level with the
list of child Items in an AND condition of the WHERE clause.

The place where this is done is:
static COND *build_equal_items_for_cond(THD *thd, COND *cond,
                                        COND_EQUAL *inherited)
{
  ...
      if (and_level)
    {
      args->concat(&eq_list);
      args->concat((List<Item> *)&cond_equal.current_level);
    }
  ...
}

As a result, later transformations on the WHERE clause may change the
structure of the list join->cond_equal->current_level without knowing this.

Specifically in this bug, Item_in_subselect::inject_in_to_exists_cond
creates a new AND of the old WHERE clause and the IN->EXISTS conditions.
It then calls fix_fields() for the new AND. Among other things, fix_fields
flattens all nested ANDs into one by merging the AND argument lists.

When there is a cond_equal for the JOIN, its list of Item_equal objects
is attached to the end of the original AND. When a lower-level AND is
merged into the top-level one, the argument list of the lower-level AND
is concatenated to the list of multiple equalities in the upper-level AND.

As a result, when substitute_for_best_equal_field processes the 
multiple equalities, it turns out that the multiple equality list contains
the Items from the lower-level AND which were concatenated to the end of
the join->cond_equal->current_level list. This results in a crash because
this list must not contain any other Items except for the previously found
Item_equal ones.

Solution:
When performing IN->EXIST predicate injection, and the where clause is an
AND, detach the list of Item_equal objects before calling fix_fields on
the injected where clause.

After fix_fields is done, reattach back the multiple equalities list to
the end of the argument list of the new AND.
2011-04-28 17:15:05 +03:00
unknown
759d71eba1 MWL#89
Split the tests for MWL#89 into two parts - one for bugs
(currently active), and one for functionality tets
(currently in progress, and thus disabled).

Disable the test for LP BUG#718593.
2011-02-22 12:44:58 +02:00