- 12 Mar, 2011 2 commits
-
-
Igor Babaev authored
-
Igor Babaev authored
Do not reset the value of the item_equal field in the Item_field object once it has been set.
-
- 11 Mar, 2011 8 commits
-
-
Vladislav Vaintroub authored
-
Vladislav Vaintroub authored
-
Vladislav Vaintroub authored
-
Vladislav Vaintroub authored
-
Vladislav Vaintroub authored
-
Vladislav Vaintroub authored
-
Vladislav Vaintroub authored
-
Vladislav Vaintroub authored
-
- 10 Mar, 2011 1 commit
-
-
Vladislav Vaintroub authored
-
- 09 Mar, 2011 3 commits
-
-
Vladislav Vaintroub authored
Address Monty's review comments
-
Michael Widenius authored
Added item.real_type() for easy access to the underlaying types for Item_ref and Item_cache_wrapper() This allows us to simplify and speed up some tests and also remove get_cached_item() sql/item.h: Added item.real_type() Removed get_cached_item() sql/opt_range.cc: Simplify test sql/sql_select.cc: Simplify test sql/sql_show.cc: Simplify test
-
Michael Widenius authored
-
- 08 Mar, 2011 4 commits
-
-
Michael Widenius authored
-
unknown authored
Analysis: The assert failed because the execution code for partial matching is designed with the assumption that NULLs on the left side are detected as early as possible, and a NULL result is returned before any lookups are performed at all. However, in the case of an Item_cache object on the left side, null was not detected properly, because detection was done via Item::is_null(), which is not implemented at all for Item_cache, and resolved to the default Item::is_null() which always returns FALSE. Solution: Use the property Item::null_value instead of is_null(), which is properly updated for Item_cache objects as well.
-
Michael Widenius authored
-
Michael Widenius authored
Don't check if LAST_IO_Error has changed as this is not a user variable and it may change depending on timing issues between master and slave
-
- 07 Mar, 2011 1 commit
-
-
Vladislav Vaintroub authored
-
- 04 Mar, 2011 6 commits
-
-
Sergey Petrunya authored
-
Michael Widenius authored
-
Michael Widenius authored
-
Michael Widenius authored
-
Sergey Petrunya authored
Generally, we should use only small letters for table names but here it's easier to fix with one --replace.
-
Sergey Petrunya authored
- cleaner code - ability to change from using pointers to offsets at some point
-
- 03 Mar, 2011 4 commits
-
-
Sergey Petrunya authored
-
Sergey Petrunya authored
-
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]
-
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.
-
- 02 Mar, 2011 1 commit
-
-
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)
-
- 01 Mar, 2011 10 commits
-
-
Michael Widenius authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
unknown authored
-
unknown authored
-
Michael Widenius authored
-
Michael Widenius authored
-
unknown authored
-
Michael Widenius authored
mysql-test/suite/sphinx/suite.pm: Update test to support 1.10-beta storage/maria/unittest/ma_test_all-t: Fixed old filenames
-
Sergey Petrunya authored
-