- 29 Jan, 2011 1 commit
-
-
Igor Babaev authored
-
- 28 Jan, 2011 1 commit
-
-
Igor Babaev authored
This bug could manifest itself when hash join over a varchar column with NULL values in some rows was used. It happened because the function key_buf_cmp erroneously returned FALSE when one of the joined key fields was null while the second was not. Also fixed two other bugs in the functions key_hashnr and key_buf_cmp that could possibly lead to wrong results for some queries that used hash join over several columns with nulls. Also reverted the latest addition of the test case for bug #45092. It had been already backported earlier.
-
- 27 Jan, 2011 1 commit
-
-
Igor Babaev authored
This was another bug in the patch for bug 698882. The new code from this patch did not ensured that substitutions of fields for best equal fields were performed on all AND-OR levels. As a result substitutions for best fields in some predicates that had been used by the range optimizer were not actually performed while range plans could employ these substitutions. This could lead to inconsistent data structures and ultimately to a crash.
-
- 26 Jan, 2011 1 commit
-
-
Igor Babaev authored
The bug was in the code of the patch fixing bug 698882. With improper casting the method store_key_field::change_source_field was called for the elements of the array TABLE_REF::key_copy that were either of a different type or not allocated at all. This caused crashes in some queries.
-
- 24 Jan, 2011 1 commit
-
-
Igor Babaev authored
hash join over equi-join conditions without supporting indexes.
-
- 23 Jan, 2011 2 commits
-
-
Igor Babaev authored
-
Igor Babaev authored
of sort_intersect scans.
-
- 22 Jan, 2011 3 commits
-
-
Igor Babaev authored
-
Igor Babaev authored
-
Igor Babaev authored
hash join over equi-join conditions without supporting indexes.
-
- 21 Jan, 2011 1 commit
-
-
unknown authored
-
- 14 Jan, 2011 10 commits
-
-
Sergei Golubchik authored
(incorrect block size)
-
Sergei Golubchik authored
-
Sergei Golubchik authored
(less not-needed copies of key pages) storage/maria/ma_rkey.c: Fixed wrong test if SEARCH_SAVE_BUFF should be set. Now we assume that if we are doing HA_READ_KEY_EXACT, we don't have to copy the last key buffer (in other words, it's not likely this will be followed by a read-next call)
-
Sergei Golubchik authored
Aria and MyISAM in create_internal_tmp_table_from_heap() (safe, as duplicates are impossible). This gives a HUGE speed boost! sql/opt_subselect.cc: Fixed problem with wrong recinfo in create_duplicate_weedout_tmp_tabl() Tagged the table with 'no_rows' so that when we create the table on disk, we only store the index data. This gave us a major speedup! sql/sql_select.cc: create_tmp_table_from_heap() now uses bulk_insert + repair_by_sort when creating Aria/MyISAM tables from HEAP tables. This gives a HUGE speed boost! storage/maria/ha_maria.cc: Extended bulk_insert() to recreate UNIQUE keys for internal temporary tables storage/maria/ma_open.c: Initialize m_info->lock.type properly for temporarly tables (needed for start_bulk_insert()) storage/maria/ma_write.c: Don't check uniques that are disabled storage/myisam/ha_myisam.cc: Extended bulk_insert() to recreate UNIQUE keys for internal temporary tables.
-
Sergei Golubchik authored
This will also enable us in the future to collect statistics for writes to internal tmp tables. sql/handler.h: Added ha_write_tmp_row() sql/opt_subselect.cc: ha_write_row -> ha_write_tmp_row sql/sql_class.h: Added ha_write_tmp_row() sql/sql_select.cc: ha_write_row -> ha_write_tmp_row
-
Sergei Golubchik authored
This makes the keys smaller (no row pointer) and gives us proper errors if we use the table wrongly. sql/sql_select.cc: Use NO_RECORD for tables that doesn't need row data. storage/maria/Makefile.am: Added ma_norec.c storage/maria/ma_check.c: Added support for NO_RECORD record format (don't store any row data) storage/maria/ma_norec.c: Added support for NO_RECORD record format storage/maria/ma_open.c: Added support for NO_RECORD record format storage/maria/ma_search.c: Added support for 0 size row pointers (used with NO_RECORD) storage/maria/ma_test1.c: Added testing of NO_RECORD record format. storage/maria/maria_chk.c: Added support for NO_RECORD storage/maria/maria_def.h: Added support for NO_RECORD storage/maria/unittest/ma_test_all-t: Added testing of NO_RECORD record format
-
Sergei Golubchik authored
temptables, not "uniques", that are hash-based keys. sql/sql_expression_cache.cc: Don't set uniques (we don't want or need an unique constraint on this table)
-
Sergei Golubchik authored
This was needed as the old code caused us to have LOTS of duplicate hash values when used by optimizer. include/m_ctype.h: Made my_hash_sort_bin() exernal storage/maria/ma_unique.c: Better hash for packed numeric data for unique handling. This was needed as the old code caused us to have LOTS of duplicate hash values when used by optimizer.
-
Sergei Golubchik authored
-
Sergei Golubchik authored
mysys/my_handler.c: Fixed typo
-
- 17 Jan, 2011 2 commits
-
-
Sergey Petrunya authored
-
Sergey Petrunya authored
-
- 16 Jan, 2011 1 commit
-
-
Igor Babaev authored
-
- 15 Jan, 2011 4 commits
-
-
Igor Babaev authored
-
Igor Babaev authored
Made sure that the optimal fields are used by TABLE_REF objects when building index access keys to joined tables. Fixed a bug in the template function that sorts the elements of a list using the bubble sort algorithm. The bug caused poor performance of the function. Also added an optimization that skips comparison with the most heavy elements that has been already properly placed in the list. Made the comparison of the fields belonging to the same Item_equal more granular: fields belonging to the same table are also ordered according to some rules.
-
Igor Babaev authored
-
Igor Babaev authored
An assertion failure was triggered for a 6-way join query that used two join buffers. The failure happened because every call of JOIN_CACHE::join_matching_records saved and restored status of all tables that were accessed before the table join_tab. It must do it only for those of them that follow the last table using a join buffer.
-
- 14 Jan, 2011 8 commits
-
-
Sergey Petrunya authored
- Backport testcases - We have a different fix because we've fixed part of the problem as part of fix for LPBUG#602574.
-
Sergey Petrunya authored
Backport testcase: BUG#45863 "Assertion failed: (fixed == 0), function fix_fields(), file item.cc, line 4448" (The fix was backported with subquery code backport)
-
Sergey Petrunya authored
3150 Olav Sandstaa 2010-05-07 Test cases for the following "ICP for InnoDB" bugs: Bug#40992 InnoDB: Crash when engine_condition_pushdown is on Bug#35080 Innodb crash at mem_block_get_len line 72 Bug#41996 multi-table delete crashes server (InnoDB table) Bug#43448 Server crashes on multi table delete with Innodb All these bugs are duplicates of either one or both of Bug 43360 or 36981. (backporting of olav@sun.com-20100226091930-qxvakxmcp6463t5w)
-
Sergey Petrunya authored
Test case backport for: Bug#42580 - Innodb's ORDER BY ..LIMIT returns no rows for null-safe operator <=> NULL
-
Sergey Petrunya authored
-
Sergey Petrunya authored
(the bug itself was fixed during the subquery code backport)
-
Sergey Petrunya authored
-
Sergey Petrunya authored
3723 oystein.grovlen@sun.com 2009-11-23 Bug#46548 (addendum) Remove KEY::extra_length. It is not in use.
-
- 13 Jan, 2011 4 commits
-
-
Sergey Petrunya authored
-
Sergey Petrunya authored
-
Sergey Petrunya authored
Bug #45092: join buffer contains two blob columns one of which is used in the key employed to access the joined table
-
Sergey Petrunya authored
Date: Mon, 01 Nov 2010 15:15:25 -0000 3272 Roy Lyseng 2010-11-01 Bug#52068: Optimizer generates invalid semijoin materialization plan When MaterializeScan semijoin strategy was used and there were one or more outer dependent tables before the semijoin tables, the scan over the materialized table was not properly reset for each row of the prefix outer tables. Example: suppose we have a join order: ot1 SJ-Mat-Scan(it2 it3) ot4 Notice that this is called a MaterializeScan, even though there is an outer table ahead of the materialized tables. Usually a MaterializeScan has the outer tables after the materialized table, but this is a special (but legal) case with outer dependent tables both before and after the materialized table. For each qualifying row from ot1, a new scan over the materialized table must be set up. The code failed to do that, so all scans after the first one returned zero rows from the materialized table.
-