1. 17 May, 2012 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #999251: Q13 from DBT3 uses table scan instead of covering index scan. · bb2af22b
      Igor Babaev authored
      The optimizer chose a less efficient execution plan due to the following
      defects of the code:
      1. the generic handler function handler::keyread_time did not take into account
         that in clustered primary keys record data is included into each index entry
      2. the function make_join_readinfo erroneously decided that index only scan
         could not be used if join cache was empoyed.
      
      Added no additional test case.
      Adjusted some of the test results.
      bb2af22b
  2. 15 May, 2012 1 commit
  3. 08 May, 2012 1 commit
  4. 07 May, 2012 2 commits
  5. 05 May, 2012 4 commits
  6. 04 May, 2012 5 commits
  7. 03 May, 2012 3 commits
  8. 02 May, 2012 1 commit
  9. 03 May, 2012 1 commit
  10. 02 May, 2012 8 commits
  11. 29 Apr, 2012 1 commit
    • Alexey Botchkov's avatar
      bug #977021 ST_BUFFER fails with the negative D. · 015c584c
      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.
      015c584c
  12. 26 Apr, 2012 1 commit
  13. 27 Apr, 2012 1 commit
    • unknown's avatar
      Fix bug lp:985667, MDEV-229 · a4336eb6
      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.
      a4336eb6
  14. 25 Apr, 2012 1 commit
  15. 24 Apr, 2012 1 commit
  16. 23 Apr, 2012 2 commits
  17. 20 Apr, 2012 1 commit
    • Vladislav Vaintroub's avatar
      LPBUG#983285 - incompatibility in frm in case of VIEWs with non-default ALGORITHM option. · a1492330
      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).
      a1492330
  18. 19 Apr, 2012 1 commit
  19. 29 Apr, 2012 1 commit
    • Alexey Botchkov's avatar
      bug #977021 ST_BUFFER fails with the negative D. · 52504f53
      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.
      52504f53
  20. 21 Apr, 2012 1 commit
  21. 19 Apr, 2012 2 commits