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.

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

- Take into account that subquery's optimization can fail because of @@max_join_size error.

- Correct handling for SJ-Materialization + outer joins (details in the comments in the code)

Do not perform index condition pushdown for conditions containing subqueries
and stored functions.

Failures on SUN Solaris. Buggy compiler there required some extra initialization
for variables. Then the 02 optimization leads to bugs when values set through the
pointer are not always taken into account. Finally, the (long long) / (long)
crashes there, the explicit typeconverstion added.
Failing innodb_plunin.innodb_gis.test fixed.

per-file comments:
  mysql-test/suite/innodb_plugin/t/innodb_gis.test
GIS issues fixed.
  sql/gcalc_slicescan.cc
GIS issues fixed.
  sql/gcalc_tools.cc
GIS issues fixed.

- Correctly handle plan refinement stage for LooseScan plans: run create_ref_for_key() if LooseScan 
  plan includes a ref access, and if we don't have any fixed key components, switch to a full index scan.

set to 'on' by default.

QPLAN_TMP_DISK, like Aria version does (otherwise slow query 
log would show Tmp_table_on_disk=No when it should have said Yes)

- Let JTBM optimization code handle the case where the subquery is degenerate and doesn't have a 
  join query plan. Regular materialization would fall back to IN->EXISTS for such cases. Semi-Join
  materialization does not have such option, instead we introduce and use "constant JTBM join tabs".

A memory overwrite in the function test_if_skip_sort_order()
could cause a crash for some queries with subqueries.

- Do a "more thorough" cleanup of SJ-Materialization join tab in JOIN_TAB::cleanup. The bug
  was due to the fact that JOIN_TAB::cleanup() may be called multiple times for the same tab
  if the join has grouping.

Updated version number in configure

sql/set_var.cc:
  Moved query_cache_strip_comments from EMBEDDED_LIBRARY to HAVE_QUERY_CACHE

mysql-test/suite/maria/r/maria-recovery3.result:
  Added test case for recovery bug
mysql-test/suite/maria/t/maria-recovery3.test:
  Added test case for recovery bug
storage/maria/ha_maria.cc:
  Don't print query twice to log
storage/maria/ma_delete.c:
  More DBUG_PRINT
storage/maria/ma_key_recover.c:
  Added new asserts to detect errors earlier
storage/maria/ma_recovery.c:
  Update all states when moving a non-transactional file to transactional. This fixes lp:887051

- Changed storage to be 2 bytes instead of sizeof(size_t) (simple optimization)
- Fixed bug when using query_cache_strip_comments and query that started with '('
- Fixed DBUG_PRINT() that used wrong (not initialized) variables.


mysql-test/mysql-test-run.pl:
  Added some space to make output more readable.
mysql-test/r/query_cache.result:
  Updated test results
mysql-test/t/query_cache.test:
  Added test with query_cache_strip_comments
sql/mysql_priv.h:
  Added QUERY_CACHE_DB_LENGTH_SIZE
sql/sql_cache.cc:
  Fixed bug when using query_cache_strip_comments and query that started with '('
  Store db length in 2 characters instead of size_t.
  Get db length from correct position (earlier we had an error when query started with ' ')
  Fixed DBUG_PRINT() that used wrong (not initialized) variables.

The range optimizer incorrectly chose a loose scan for group by
when there is a correlated WHERE condition. This range access
method cannot be executed for correlated conditions also with the
"range checked for each record" because generally the range access
method can change for each outer record. Loose scan destructively
changes the query plan and removes the GROUP operation, which will
result in wrong query plans if another range access is chosen
dynamically.