1. 17 May, 2012 1 commit
    • unknown's avatar
      Fix for bug lp:944706, task MDEV-193 · da521483
      unknown authored
      The patch enables back constant subquery execution during
      query optimization after it was disabled during the development
      of MWL#89 (cost-based choice of IN-TO-EXISTS vs MATERIALIZATION).
      
      The main idea is that constant subqueries are allowed to be executed
      during optimization if their execution is not expensive.
      
      The approach is as follows:
      - Constant subqueries are recursively optimized in the beginning of
        JOIN::optimize of the outer query. This is done by the new method
        JOIN::optimize_constant_subqueries(). This is done so that the cost
        of executing these queries can be estimated.
      - Optimization of the outer query proceeds normally. During this phase
        the optimizer may request execution of non-expensive constant subqueries.
        Each place where the optimizer may potentially execute an expensive
        expression is guarded with the predicate Item::is_expensive().
      - The implementation of Item_subselect::is_expensive has been extended
        to use the number of examined rows (estimated by the optimizer) as a
        way to determine whether the subquery is expensive or not.
      - The new system variable "expensive_subquery_limit" controls how many
        examined rows are considered to be not expensive. The default is 100.
      
      In addition, multiple changes were needed to make this solution work
      in the light of the changes made by MWL#89. These changes were needed
      to fix various crashes and wrong results, and legacy bugs discovered
      during development.
      da521483
  2. 08 May, 2012 1 commit
  3. 07 May, 2012 2 commits
  4. 05 May, 2012 4 commits
  5. 04 May, 2012 5 commits
  6. 03 May, 2012 3 commits
  7. 02 May, 2012 1 commit
  8. 03 May, 2012 1 commit
  9. 02 May, 2012 8 commits
  10. 29 Apr, 2012 1 commit
    • Alexey Botchkov's avatar
      bug #977021 ST_BUFFER fails with the negative D. · af084bcd
      Alexey Botchkov authored
        Points and lines should disappear if we got negative D.
        To make it work properly inside the GEOMETRYCOLLECTION,
        we add the empty operation there.
      
      bug #986977 Assertion `!cur_p->event' failed in Gcalc_scan_iterator::arrange_event(int, int).
        The double->inernal coord conversion produced -0 (minus zero) on some data.
        That minus-zero produces invalid comparison results when compared agains plus-zero.
        So we fixed the gcalc_set_double() to avoid it.
      
      per-file comments:
        mysql-test/r/gis-precise.result
              result updated.
        mysql-test/t/gis-precise.test
              tests for #977021 and #986977 added.
        sql/gcalc_slicescan.cc
              bug #986977. The gcalc_set_double fixed to not produce minus-zero.
        sql/item_geofunc.cc
              bug #977021. Add the NOOP for the disappearing features.
      af084bcd
  11. 26 Apr, 2012 1 commit
  12. 27 Apr, 2012 1 commit
    • unknown's avatar
      Fix bug lp:985667, MDEV-229 · c04786d3
      unknown authored
      Analysis:
      
      The reason for the wrong result is the interaction between constant
      optimization (in this case 1-row table) and subquery optimization.
      
      - First the outer query is optimized, and 'make_join_statistics' finds that
      table t2 has one row, reads that row, and marks the whole table as constant.
      This also means that all fields of t2 are constant.
      
      - Next, we optimize the subquery in the end of the outer 'make_join_statistics'.
      The field 'f2' is considered constant, with value '3'. The subquery predicate
      is rewritten as the constant TRUE.
      
      - The outer query execution detects early that the whole query result is empty
      and calls 'return_zero_rows'. Since the query is with implicit grouping, we
      have to produce one row with special values for the aggregates (depending on
      each aggregate function), and NULL values for all non-aggregate fields.  This
      function calls 'no_rows_in_result' to set each aggregate function to the
      default value when it aggregates over an empty result, and then calls
      'send_data', which in turn evaluates each Item in the SELECT list.
      
      - When evaluation reaches the subquery predicate, it executes the subquery
      with field 'f2' having a constant value '3', and the subquery produces the
      incorrect result '7'.
      
      Solution:
      
      Implement Item::no_rows_in_result for all subquery predicates. In order to
      make this work, it is also needed to make all val_* methods of all subquery
      predicates respect the Item_subselect::forced_const flag. Otherwise subqueries
      are executed anyways, and override the default value set by no_rows_in_result
      with whatever result is produced from the subquery evaluation.
      c04786d3
  13. 25 Apr, 2012 1 commit
  14. 24 Apr, 2012 1 commit
  15. 23 Apr, 2012 2 commits
  16. 20 Apr, 2012 1 commit
    • Vladislav Vaintroub's avatar
      LPBUG#983285 - incompatibility in frm in case of VIEWs with non-default ALGORITHM option. · 97aa8e8c
      Vladislav Vaintroub authored
      As part of derived tables redesign, values for VIEW_ALGORITHM_MERGE and VIEW_ALGORITHM_TMPTABLE have changed from (former values 1 rsp 2 , new values 5 rsp 9).
      
      This lead to the problem that views, created with version 5.2  or earlier would not work in all situations  (e.g "SHOW CREATE VIEW"), or with mysqldump.
      
      The fix is to restore backward compatibility for the from file, and convert algorithm={1,2} in the frm to {5,9} when reading .frm from disk, and store backward compatible values when writing from to disk. 
      
      Also allow processing correct processing for "invalid" .frms created with MariaDB 5.3/5.5 GA releases (where algorithm stored in memory matched the one stored in frm).
      97aa8e8c
  17. 19 Apr, 2012 1 commit
  18. 29 Apr, 2012 1 commit
    • Alexey Botchkov's avatar
      bug #977021 ST_BUFFER fails with the negative D. · d16ea779
      Alexey Botchkov authored
        Points and lines should disappear if we got negative D.
        To make it work properly inside the GEOMETRYCOLLECTION,
        we add the empty operation there.
      
      bug #986977 Assertion `!cur_p->event' failed in Gcalc_scan_iterator::arrange_event(int, int).
        The double->inernal coord conversion produced -0 (minus zero) on some data.
        That minus-zero produces invalid comparison results when compared agains plus-zero.
        So we fixed the gcalc_set_double() to avoid it.
      
      per-file comments:
        mysql-test/r/gis-precise.result
              result updated.
        mysql-test/t/gis-precise.test
              tests for #977021 and #986977 added.
        sql/gcalc_slicescan.cc
              bug #986977. The gcalc_set_double fixed to not produce minus-zero.
        sql/item_geofunc.cc
              bug #977021. Add the NOOP for the disappearing features.
      d16ea779
  19. 21 Apr, 2012 1 commit
  20. 19 Apr, 2012 3 commits