- 31 Jan, 2007 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
Two problems here: Problem 1: While constructing the join columns list the optimizer does as follows: 1. Sets the join_using_fields/natural_join members of the right JOIN operand. 2. Makes a "table reference" (TABLE_LIST) to parent the two tables. 3. Assigns the join_using_fields/is_natural_join of the wrapper table using join_using_fields/natural_join of the rightmost table 4. Sets join_using_fields to NULL for the right JOIN operand. 5. Passes the parent table up to the same procedure on the upper level. Step 1 overrides the the join_using_fields that are set for a nested join wrapping table in step 4. Fixed by making a designated variable SELECT_LEX::prev_join_using to pass the data from step 1 to step 4 without destroying the wrapping table data. Problem 2: The optimizer checks for ambiguous columns while transforming NATURAL JOIN/JOIN USING to JOIN ON. While doing that there was no distinction between columns that are used in the generated join condition (where ambiguity can be checked) and the other columns (where ambiguity can be checked only when resolving references coming from outside the JOIN construct itself). Fixed by allowing the non-USING columns to be present in multiple copies in both sides of the join and moving the ambiguity check to the place where unqualified references to the join columns are resolved (find_field_in_natural_join()).
-
- 15 Jan, 2007 7 commits
-
-
igor@olga.mysql.com authored
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/mysql-5.0-opt
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/mysql-5.0-opt
-
evgen@moonbone.local authored
Fix for crashes on 64bit platforms after fixing bug#23417.
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/mysql-5.0-opt
-
gkodinov/kgeorge@rakia.gmz authored
into rakia.gmz:/home/kgeorge/mysql/autopush/B20420-5.0-opt
-
gkodinov/kgeorge@macbook.gmz authored
The optimizer needs to evaluate whether predicates are better evaluated using an index. IN is one such predicate. To qualify an IN predicate must involve a field of the index on the left and constant arguments on the right. However whether an expression is a constant can be determined only by knowing the preceding tables in the join order. Assuming that only IN predicates with expressions on the right that are constant for the whole query qualify limits the scope of possible optimizations of the IN predicate (more specifically it doesn't allow the "Range checked for each record" optimization for such an IN predicate. Fixed by not pre-determining the optimizability of the IN predicate in the case when all right IN operands are not SQL constant expressions
-
- 13 Jan, 2007 1 commit
-
-
igor@olga.mysql.com authored
for queries using 'range checked for each record'. The problem was fixed in 5.0 by the patch for bug 12291. This patch down-ported the corresponding code from 5.0 into QUICK_SELECT::init() and added a new test case.
-
- 12 Jan, 2007 4 commits
-
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/mysql-5.0-opt
-
igor@olga.mysql.com authored
in a select list. The objects of the Item_trigger_field class inherited the implementations of the methods copy_or_same, get_tmp_table_item and get_tmp_table_field from the class Item_field while they rather should have used the default implementations defined for the base class Item. It could cause catastrophic problems for triggers that used SELECTs with select list containing trigger fields such as NEW.<table column> under DISTINCT.
-
evgen@moonbone.local authored
After merge fix
-
evgen@moonbone.local authored
into moonbone.local:/work/latest-5.0-opt-mysql
-
- 11 Jan, 2007 8 commits
-
-
evgen@moonbone.local authored
into moonbone.local:/work/23417-bug-5.0-opt-mysql
-
evgen@moonbone.local authored
Currently in the ONLY_FULL_GROUP_BY mode no hidden fields are allowed in the select list. To ensure this each expression in the select list is checked to be a constant, an aggregate function or to occur in the GROUP BY list. The last two requirements are wrong and doesn't allow valid expressions like "MAX(b) - MIN(b)" or "a + 1" in a query with grouping by a. The correct check implemented by the patch will ensure that: any field reference in the [sub]expressions of the select list is under an aggregate function or is mentioned as member of the group list or is an outer reference or is part of the select list element that coincide with a grouping element. The Item_field objects now can contain the position of the select list expression which they belong to. The position is saved during the field's Item_field::fix_fields() call. The non_agg_fields list for non-aggregated fields is added to the SELECT_LEX class. The SELECT_LEX::cur_pos_in_select_list now contains the position in the select list of the expression being currently fixed.
-
gkodinov/kgeorge@rakia.gmz authored
into rakia.gmz:/home/kgeorge/mysql/autopush/B25106-5.0-opt
-
gkodinov/kgeorge@macbook.gmz authored
aliases ignored When a column reference to a column in JOIN USING is resolved and a new Item is created for this column the user defined name was lost. This fix preserves the alias by setting the name of the new Item to the original alias.
-
evgen@moonbone.local authored
correctly. The Item_func::print method was used to print the Item_func_encode and the Item_func_decode objects. The last argument to ENCODE and DECODE functions is a plain C string and thus Item_func::print wasn't able to print it. The print() method is added to the Item_func_encode class. It correctly prints the Item_func_encode and the Item_func_decode objects.
-
evgen@moonbone.local authored
-
evgen@moonbone.local authored
WHERE is present. If a DELETE statement with ORDER BY and LIMIT contains a WHERE clause with conditions that for sure cannot be used for index access (like in WHERE @var:= field) the execution always follows the filesort path. It happens currently even when for the above case there is an index that can be used to speedup sorting by the order by list. Now if a DELETE statement with ORDER BY and LIMIT contains such WHERE clause conditions that cannot be used to build any quick select then the mysql_delete() tries to use an index like there is no WHERE clause at all.
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/d2/hf/mr10/my50-mr10
-
- 10 Jan, 2007 10 commits
-
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/mysql-4.1-opt
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/mysql-5.0-opt
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/d2/hf/mr10/my50-mr10
-
kent@mysql.com/kent-amd64.(none) authored
Removed line accidently inserted when correcting bug#18526
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/d2/hf/mr10/my50-mr10
-
gluh@mysql.com/eagle.(none) authored
-
gluh@mysql.com/eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.0-opt
-
gluh@mysql.com/eagle.(none) authored
2nd version During tmp tables cleanup we get the handler for temporary table and delete table using handler method.
-
igor@olga.mysql.com authored
In the method Item_field::fix_fields we try to resolve the name of the field against the names of the aliases that occur in the select list. This is done by a call of the function find_item_in_list. When this function finds several occurrences of the field name it sends an error message to the error queue and returns 0. Yet the code did not take into account that find_item_in_list could return 0 and tried to dereference the returned value.
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/mysql-5.0-opt
-
- 09 Jan, 2007 9 commits
-
-
joerg@trift2. authored
support-files/MySQL-shared-compat.spec.sh : Dummy, irrelevant change - just trigger a new build.
-
evgen@moonbone.local authored
used. The Item::save_in_field() function is called from fill_record() to fill the new row with data while execution of the CREATE TABLE ... SELECT statement. Item::save_in_field() calls val_xxx() methods in order to get values. val_xxx() methods do not take into account the result field. Due to this Item_func_set_user_var::val_xxx() methods returns values from the original table, not from the temporary one. The save_in_field() member function is added to the Item_func_set_user_var class. It detects whether the result field should be used and properly updates the value of the user variable.
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/mysql-5.0-opt
-
evgen@moonbone.local authored
A BINARY field is represented by the Field_string class. The space character is used as the filler for unused characters in such a field. But a BINARY field should use \x00 instead. Field_string:reset() now detects whether the current field is a BINARY one and if so uses the \x00 character as a default value filler.
-
evgen@moonbone.local authored
into moonbone.local:/home/evgen/bk-trees/mysql-5.0-opt
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug25027
-
thek@kpdesk.mysql.com authored
into kpdesk.mysql.com:/home/thek/dev/mysql-5.0-build
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/d2/hf/opt/my50-opt
-
thek@kpdesk.mysql.com authored
into kpdesk.mysql.com:/home/thek/dev/bug23010/my50-bug23010
-