lp:~jiangchengyao/+junk/mariadb

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

3371. By David Jiang on 2011-12-29

add physical & logical io statistics in slow log.

3370. By Sergey Petrunia on 2011-12-27

Merge

3369. By Igor Babaev on 2011-12-26

Changed a test case from join_cache.test to make it platform independent.

3368. By Igor Babaev on 2011-12-24

Back-ported the patch of the mysql-5.6 code line that

fixed several defects in the greedy optimization:

1) The greedy optimizer calculated the 'compare-cost' (CPU-cost)
   for iterating over the partial plan result at each level in
   the query plan as 'record_count / (double) TIME_FOR_COMPARE'

   This cost was only used locally for 'best' calculation at each
   level, and *not* accumulated into the total cost for the query plan.

   This fix added the 'CPU-cost' of processing 'current_record_count'
   records at each level to 'current_read_time' *before* it is used as
   'accumulated cost' argument to recursive
   best_extension_by_limited_search() calls. This ensured that the
   cost of a huge join-fanout early in the QEP was correctly
   reflected in the cost of the final QEP.

   To get identical cost for a 'best' optimized query and a
   straight_join with the same join order, the same change was also
   applied to optimize_straight_join() and get_partial_join_cost()

2) Furthermore to get equal cost for 'best' optimized query and a
   straight_join the new code substrcated the same '0.001' in
   optimize_straight_join() as it had been already done in
   best_extension_by_limited_search()

3) When best_extension_by_limited_search() aggregated the 'best' plan a
   plan was 'best' by the check :

   'if ((search_depth == 1) || (current_read_time < join->best_read))'

   The term '(search_depth == 1' incorrectly caused a new best plan to be
   collected whenever the specified 'search_depth' was reached - even if
   this partial query plan was more expensive than what we had already
   found.

3367. By Sergey Petrunia on 2011-12-20

Fix version number: it's 5.3.3

3366. By Sergey Petrunia on 2011-12-20

Update mysql-test/suite/pbxt/r/subselect.result for the previous push

3365. By Timour Katchaounov on 2011-12-19

Backport of WL#5953 from MySQL 5.6

The patch differs from the original MySQL patch as follows:
- All test case differences have been reviewed one by one, and
  care has been taken to restore the original plan so that each
  test case executes the code path it was designed for.
- A bug was found and fixed in MariaDB 5.3 in
  Item_allany_subselect::cleanup().
- ORDER BY is not removed because we are unsure of all effects,
  and it would prevent enabling ORDER BY ... LIMIT subqueries.
- ref_pointer_array.m_size is not adjusted because we don't do
  array bounds checking, and because it looks risky.

Original comment by Jorgen Loland:
-------------------------------------------------------------
WL#5953 - Optimize away useless subquery clauses

For IN/ALL/ANY/SOME/EXISTS subqueries, the following clauses are
meaningless:

* ORDER BY (since we don't support LIMIT in these subqueries)
* DISTINCT
* GROUP BY if there is no HAVING clause and no aggregate
  functions

This WL detects and optimizes away these useless parts of the
query during JOIN::prepare()

3364. By Sergey Petrunia on 2011-12-19

BUG#906385: EXPLAIN EXTENDED crashes in TABLE_LIST::print with limited max_join_size
- Take into account that subquery's optimization can fail because of @@max_join_size error.

3363. By Sergey Petrunia on 2011-12-19

BUG#904432: Wrong result with LEFT JOIN, constant table, semijoin=ON,materialization=ON
- Correct handling for SJ-Materialization + outer joins (details in the comments in the code)

3362. By Sergey Petrunia on 2011-12-19

Remove garbage comments