1. 12 Mar, 2011 2 commits
  2. 11 Mar, 2011 8 commits
  3. 10 Mar, 2011 1 commit
  4. 09 Mar, 2011 3 commits
  5. 08 Mar, 2011 4 commits
  6. 07 Mar, 2011 1 commit
  7. 04 Mar, 2011 6 commits
  8. 03 Mar, 2011 4 commits
    • Sergey Petrunya's avatar
      Merge fix for BUG#693747 · 57f7ca42
      Sergey Petrunya authored
      57f7ca42
    • Sergey Petrunya's avatar
      Merge BUG#707925. · e21fd5ac
      Sergey Petrunya authored
      e21fd5ac
    • Sergey Petrunya's avatar
      BUG#707925: Wrong result with join_cache_level=6 optimizer_use_mrr = force (incremental, BKA join) · 3c69d4f2
      Sergey Petrunya authored
      - The problem was that Mrr_ordered_index_reader's interrupt_read() and resume_read() would 
        save and restore 1) index tuple  2) the rowid (as bytes returned by handler->position()).  Clustered 
        primary key columns were not saved/restored. 
        They are not explicitly present in the index tuple (i.e. table->key_info[secondary_key].key_parts 
        doesn't list them), but they are actually there, in particular 
        table->field[clustered_primary_key_member].part_of_key(secondary_key) == 1. Index condition pushdown
        code [correctly] uses the latter as inidication that pushed index condition can refer to clustered PK
        members. 
      
        The fix was to make interrupt_read()/resume_read() to save/restore clustered primary key members as well,
        so that we get correct values for them when evaluating pushed index condition.
      [3rd attempt: remove the debugging aids, fix comments in testcase]
      3c69d4f2
    • unknown's avatar
      Fix LP BUG#718763 · 5dfb33be
      unknown authored
      Analysis:
      The reason for the crash was that the inner subquery was executed
      via a scan on a final temporary table applied after all other
      operations. This final operation is implemented by changing the
      contents of the JOIN object of the subquery to represent a table
      scan over the temp table. At the same time query optimization of
      the outer subquery required evaluation of the inner subquery, which
      happened before the actual EXPLAIN. The evaluation left the JOIN
      object of the inner subquery in the changed state, where it represented
      a table scan over a temp table, and EXPLAIN crashed because the temp
      table is not associated with any table reference (TABLE_LIST object).
      The reason the JOIN was not restored was because its saving/restoration
      was controlled by the join->select_lex->uncacheable flag, which was
      not set in the case of materialization.
      
      Solution:
      In the methods Item_in_subselect::[single | row]_value_transformer() set:
          select_lex->uncacheable|= UNCACHEABLE_EXPLAIN;
      In addition, for symmetry, change:
          master_unit->uncacheable|= UNCACHEABLE_EXPLAIN;
      instead of UNCACHEABLE_DEPENDENT because if a subquery was not
      dependent initially, the changed methods do not change this
      fact. The subquery may later become correlated if it is transformed
      to an EXISTS query, but it may stay uncorrelated if executed via
      materialization.
      5dfb33be
  9. 02 Mar, 2011 1 commit
    • Sergey Petrunya's avatar
      BUG#693747: Assertion multi_range_read.cc:908: int DsMrr_impl::dsmrr_init · 75bd2a0e
      Sergey Petrunya authored
      - Make DsMrr_impl::dsmrr_init() handle the case of 
         1. 1st MRR scan using DS-MRR strategy (i.e. doing key sorting and rowid sorting)
         2. 2nd MRR scan getting a buffer that's too small to fit one key element 
            and one rowid element, and so falling back to default MRR implementation
        In this case, dsmrr_init() is invoked with {primary_handler, secondary_handler}
        initialized for DS-MRR scan and have to reset them to be initialized for the
        default MRR scan.
      (attempt 2, with simplified testcase)
      75bd2a0e
  10. 01 Mar, 2011 10 commits