An error occurred fetching the project authors.
- 05 Nov, 2010 1 commit
-
-
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.
-
- 30 Oct, 2010 1 commit
-
-
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.
-
- 27 Oct, 2010 1 commit
-
-
Igor Babaev authored
-
- 24 Oct, 2010 1 commit
-
-
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.
-
- 22 Oct, 2010 1 commit
-
-
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.
-
- 04 Oct, 2010 1 commit
-
-
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().
-
- 01 Oct, 2010 2 commits
-
-
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.
-
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.
-
- 28 Sep, 2010 1 commit
-
-
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.
-
- 23 Sep, 2010 1 commit
-
-
Igor Babaev authored
-
- 21 Sep, 2010 1 commit
-
-
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.
-
- 31 Aug, 2010 1 commit
-
-
Igor Babaev authored
-
- 06 Mar, 2010 1 commit
-
-
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.
-
- 21 Dec, 2009 1 commit
-
-
Igor Babaev authored
WL#2771 "Block Nested Loop Join and Batched Key Access Join"
-