An error occurred fetching the project authors.
  1. 05 Nov, 2010 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #669382. · 615d7567
      Igor Babaev authored
      When probing into the hash table of a hashed join cache is performed
      the key value should not constructed in the buffer used to build keys
      in the hash tables. The constant parts of these keys copied only once,
      so they should not be ever overwritten. Otherwise wrong results
      can be produced by queries that employ hashed join buffers.
      615d7567
  2. 30 Oct, 2010 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #668290. · df323421
      Igor Babaev authored
      Prohibited to use hash join algorithm BNLH if join attributes
      need non-binary collations. It has to be done because BNLH does
      not support join for such attributes yet.
      Later this limitations will be lifted.
      
      Changed default collations for the schemes of some test cases
      to preserve the old execution plans.
      df323421
  3. 27 Oct, 2010 1 commit
  4. 24 Oct, 2010 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #664508. · 0c53cd1e
      Igor Babaev authored
      When join buffers are employed no index scan for the first
      table with grouping columns can be used.
      
      
      
      mysql-test/r/join_cache.result:
        Added a test case for bug #664508.
        Sorted results for some other test cases.
      mysql-test/t/join_cache.test:
        Added a test case for bug #664508.
        Sorted results for some other test cases.
      0c53cd1e
  5. 22 Oct, 2010 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #663840. · ca862231
      Igor Babaev authored
      When adding a new record into the join buffer that is employed by
      BNLH join algorithm the writing procedure JOIN_CACHE::write_record_data 
      checks whether there is enough space for the record in the buffer.
      When doing this it must take into account a possible new key entry
      added to the buffer. It might happen, as it has been demonstrated by
      the bug test case, that there is enough remaining space in the buffer
      for the record, but not for the additional key entry for this record.
      In this case the key entry overwrites the end of the record that might
      cause a crash or wrong results.
      Fixed by taking into account a possible addition of new key entry when
      estimating the remaining free space in the buffer.
      ca862231
  6. 04 Oct, 2010 1 commit
    • Igor Babaev's avatar
      Applied the fix for bug #54235 taken from one of the mysql trees. · f1d42ec9
      Igor Babaev authored
      The fix aligns join_null_complements() with join_matching_records()
      making both call generate_full_extensions().
      There should not be any difference between how the WHERE clause
      is applied to NULL-complemented records from a partial join and how
      it is applied to other partially joined records:the latter happens in
      join_matching_records(), precisely in generate_full_extensions().
      f1d42ec9
  7. 01 Oct, 2010 2 commits
    • Igor Babaev's avatar
      Fixed bug #54539. · 4bc234f3
      Igor Babaev authored
      Added a possibility not to factor out the condition pushed to
      the access index out of the condition pushed to a joined table.
      This is useful for the condition pushed to the index when a hashed
      join buffer for BKA is employed. In this case the index condition
      may be false for some, but for all records with the same key.
      So the condition must be checked not only after index lookup,
      but after fetching row data as well, and it makes sense not to 
      factor out the condition from the condition checked after reading
      row data,
      The bug happened because the condition pushed to an index always
      was factor out from the condition pushed to the accessed table. 
      
      ******
      Fixed bug #54539.
      Added a possibility not to factor out the condition pushed to
      the access index out of the condition pushed to a joined table.
      This is useful for the condition pushed to the index when a hashed
      join buffer for BKA is employed. In this case the index condition
      may be false for some, but for all records with the same key.
      So the condition must be checked not only after index lookup,
      but after fetching row data as well, and it makes sense not to 
      factor out the condition from the condition checked after reading
      row data,
      The bug happened because the condition pushed to an index always
      was factor out from the condition pushed to the accessed table. 
      4bc234f3
    • Igor Babaev's avatar
      Fixed bug #54539. · 1320f607
      Igor Babaev authored
      Added a possibility not to factor out the condition pushed to
      the access index out of the condition pushed to a joined table.
      This is useful for the condition pushed to the index when a hashed
      join buffer for BKA is employed. In this case the index condition
      may be false for some, but for all records with the same key.
      So the condition must be checked not only after index lookup,
      but after fetching row data as well, and it makes sense not to 
      factor out the condition from the condition checked after reading
      row data,
      The bug happened because the condition pushed to an index always
      was factor out from the condition pushed to the accessed table. 
      1320f607
  8. 28 Sep, 2010 1 commit
    • Igor Babaev's avatar
      Fixed bug #52636. · 21b1b5f0
      Igor Babaev authored
      Applied the fix for bug #47217 from the mysql-6.0 codebase.
      The patch adds not null predicates generated for the left parts
      of the equality predicates used for ref accesses. This is done
      for such predicates both in where conditions and on conditions.
      For the where conditions the not null predicates were generated
      but in 5.0/5.1 they actually never were used due to some lame
      merge from 4.1 to 5.0. The fix for bug #47217 made these 
      predicates to be used in the condition pushed to the tables.
      Yet only this patch generates not null predicates for equality
      predicated from on conditions of outer joins.
      This patch introduces a performance regression that can be
      observed on a test case from null_key.test. The regression
      will disappear after the fix for bug #57024 from mariadb-5.1
      is pulled into mariadb-5.3.
      The patch contains many changes in the outputs of the EXPLAIN 
      commands since generated not null predicates are considered as
      parts of the conditions pushed to join tables and may add
      'Usingwhere' in some rows of EXPLAINs where there used
      to be no such comments.
      21b1b5f0
  9. 23 Sep, 2010 1 commit
  10. 21 Sep, 2010 1 commit
    • Igor Babaev's avatar
      Fixed bug #52394 / LP bug #623209. · f4503f39
      Igor Babaev authored
      When an incremental join cache is used to join a table whose
      fields are not referenced anywhere in the query the association
      pointer to the last record in the such cache can be the same
      as the pointer to the end of the buffer. 
      The function JOIN_CACHE_BKA::get_next_key must take into 
      consideration this when iterating over the keys of the records
      from the join buffer. 
      The assertion in JOIN_TAB_SCAN_MRR::next also must take this
      into consideration.
      Borrowed a slightly changed test case from a patch attached to the
      bug #52394.
      f4503f39
  11. 31 Aug, 2010 1 commit
  12. 06 Mar, 2010 1 commit
    • Igor Babaev's avatar
      Fixed bug #51092. · 1c7ba7ba
      Igor Babaev authored
      The function JOIN_CACHE::read_all_record_fields could return 0
      for an incremental join cache in two cases:
      1. there were no more records in the associated join buffer
      2. there was no table fields stored in the join buffer.
      As a result the function JOIN_CACHE::get_record() could
      return prematurely and did not read all needed fields from
      join buffers into the record buffer.
      
      Now the function JOIN_CACHE::read_all_record_fields returns
      -1 if there are no more records in the associated join buffer.
      1c7ba7ba
  13. 21 Dec, 2009 1 commit