An error occurred fetching the project authors.
- 02 Aug, 2007 1 commit
-
-
igor@olga.mysql.com authored
This patch adds cost estimation for the queries with ORDER BY / GROUP BY and LIMIT. If there was a ref/range access to the table whose rows were required to be ordered in the result set the optimizer always employed this access though a scan by a different index that was compatible with the required order could be cheaper to produce the first L rows of the result set. Now for such queries the optimizer makes a choice between the cheapest ref/range accesses not compatible with the given order and index scans compatible with it.
-
- 04 Apr, 2007 2 commits
-
-
igor@olga.mysql.com authored
-
igor@olga.mysql.com authored
-
- 03 Apr, 2007 1 commit
-
-
igor@olga.mysql.com authored
IN/BETWEEN predicates in sorting expressions. Wrong results may occur when the select list contains an expression with IN/BETWEEN predicate that differs from a sorting expression by an additional NOT only. Added the method Item_func_opt_neg::eq to compare correctly expressions containing [NOT] IN/BETWEEN. The eq method inherited from the Item_func returns TRUE when comparing 'a IN (1,2)' with 'a NOT IN (1,2)' that is not, of course, correct.
-
- 07 Mar, 2007 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
DATE/DATETIME values are out of the currently supported 4 basic value types (INT,STRING,REAL and DECIMAL). So expressions (not fields) of compile type DATE/DATETIME are generally considered as STRING values. This is not so when they are compared : then they are compared as INTEGER values. But the rule for comparison as INTEGERS must be checked explicitly each time when a comparison is to be performed. filesort is one such place. However there the check was not done and hence the expressions (not fields) of type DATE/DATETIME were sorted by their string representation. Fixed to compare them as INTEGER values for filesort.
-
- 06 Mar, 2007 1 commit
-
-
evgen@moonbone.local authored
Functions over sum functions wasn't set up correctly for the ORDER BY clause which leads to a wrong order of the result set. The split_sum_func() function is called now for each ORDER BY item that contains a sum function to set it up correctly.
-
- 09 Feb, 2007 1 commit
-
-
"update existingtable set anycolumn=nonexisting order by nonexisting" would crash the server. Though we would find the reference to a field, that doesn't mean we can then use it to set some values. It could be a reference to another field. If it is NULL, don't try to use it to set values in the Item_field and instead return an error. Over the previous patch, this signals an error at the location of the error, rather than letting the subsequent deref signal it.
-
- 22 Jan, 2007 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
st_table::const_key_parts member is used in determining if certain key has a prefix that is compared to constant(s) in the query predicates. If there's such prefix the index can be used to get the data from the remaining suffix columns in sorted order. However if a field is compared to another field from a "const" table the const_key_parts is not amended. This makes the optimizer unable to detect that the key can be used for sorting and adds an extra filesort. Fixed by updating const_key_parts after reading in the "const" table.
-
- 10 Jan, 2007 1 commit
-
-
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.
-
- 17 Nov, 2006 1 commit
-
-
holyfoot/hf@mysql.com/deer.(none) authored
-
- 03 Nov, 2006 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
The parser is allocating Item_field for references by name in ORDER BY expressions. Such expressions however may point not only to Item_field in the select list (or to a table column) but also to an arbitrary Item. This causes Item_field::fix_fields to throw an error about missing column. The fix substitutes Item_field for the reference with an Item_ref when not pointing to Item_field.
-
- 29 Sep, 2006 1 commit
-
-
sergefp@mysql.com authored
-
- 15 Aug, 2006 2 commits
-
-
gkodinov/kgeorge@macbook.gmz authored
- undeterminstic tests fixed
-
gkodinov/kgeorge@rakia.(none) authored
on a second table in a join - undeterministic output of the test case removed.
-
- 14 Aug, 2006 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
table in a join The optimizer removes redundant columns in ORDER BY. It is considering redundant every reference to const table column, e.g b in : create table t1 (a int, b int, primary key(a)); select 1 from t1 order by b where a = 1 But it must not remove references to const table columns if the const table is an outer table because there still can be 2 values : the const value and NULL. e.g.: create table t1 (a int, b int, primary key(a)); select t2.b c from t1 left join t1 t2 on (t1.a = t2.a and t2.a = 5) order by c;
-
- 18 Jul, 2006 1 commit
-
-
jimw@rama.(none) authored
When a default of '' was specified for TEXT/BLOB columns, the specification was silently ignored. This is presumably to be nice to applications (or people) who generate their column definitions in a not-very-clever fashion. For clarity, doing this now results in a warning, or an error in strict mode.
-
- 21 Apr, 2006 1 commit
-
-
igor@rurik.mysql.com authored
The bug caused wrong result sets for union constructs of the form (SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2. For such queries order lists were concatenated and limit clause was completely neglected.
-
- 23 Aug, 2005 1 commit
-
-
timour@mysql.com authored
* Provide backwards compatibility extension to name resolution of coalesced columns. The patch allows such columns to be qualified with a table (and db) name, as it is in 4.1. Based on a patch from Monty. * Adjusted tests accordingly to test both backwards compatible name resolution of qualified columns, and ANSI-style resolution of non-qualified columns. For this, each affected test has two versions - one with qualified columns, and one without.
-
- 12 Aug, 2005 1 commit
-
-
timour@mysql.com authored
"Process NATURAL and USING joins according to SQL:2003". * Some of the main problems fixed by the patch: - in "select *" queries the * expanded correctly according to ANSI for arbitrary natural/using joins - natural/using joins are correctly transformed into JOIN ... ON for any number/nesting of the joins. - column references are correctly resolved against natural joins of any nesting and combined with arbitrary other joins. * This patch also contains a fix for name resolution of items inside the ON condition of JOIN ... ON - in this case items must be resolved only against the JOIN operands. To support such 'local' name resolution, the patch introduces a stack of name resolution contexts used at parse time. NOTICE: - This patch is not complete in the sense that - there are 2 test cases that still do not pass - one in join.test, one in select.test. Both are marked with a comment "TODO: WL#2486". - it does not include a new test specific for the task
-
- 26 Jan, 2005 1 commit
-
-
igor@rurik.mysql.com authored
Added test case for bug #7672 that existed only in 4.0.
-
- 25 Jan, 2005 1 commit
-
-
igor@rurik.mysql.com authored
Added a test case for bug #7672. sql_yacc.yy: Fixed bug #7672. Made queries of the form (SELECT ...) ORDER BY ... to be equivalent to SELECT ... ORDER BY ...
-
- 18 Jan, 2005 1 commit
-
-
monty@mysql.com authored
-
- 17 Jan, 2005 1 commit
-
-
timour@mysql.com authored
-
- 15 Jan, 2005 1 commit
-
-
jimw@mysql.com authored
are not specified in an insert. Most of these changes are actually to clean up the test suite to either specify defaults to avoid warnings, or add the warnings to the results. Related to bug #5986.
-
- 06 Jan, 2005 1 commit
-
-
timour@mysql.com authored
The problem was that when a QUICK_SELECT access method is chosen, test_if_skip_sort_order() discovered that the index being used by the quick select will not deliver tuples in sorted order. In this case test_if_skip_sort_order() tried to change the index used by the quick select, but it didn't properly set the other members of the quick select, and especially the range flags of the ranges in QUICK_SELECT::ranges. The fix re-invokes the function SQL_SELECT::test_quick_select to correctly create a valid QUICK_SELECT object.
-
- 06 Dec, 2004 1 commit
-
-
monty@mysql.com authored
Renamed HA_VAR_LENGTH to HA_VAR_LENGTH_PART Renamed in all files FIELD_TYPE_STRING and FIELD_TYPE_VAR_STRING to MYSQL_TYPE_STRING and MYSQL_TYPE_VAR_STRING to make it easy to catch all possible errors Added support for VARCHAR KEYS to heap Removed support for ISAM Now only long VARCHAR columns are changed to TEXT on demand (not CHAR) Internal temporary files can now use fixed length tables if the used VARCHAR columns are short
-
- 25 Nov, 2004 1 commit
-
-
serg@serg.mylan authored
-
- 30 Sep, 2004 1 commit
-
-
dlenev@brandersnatch.localdomain authored
identical to another in result" According to SQL standard queries like "select t1.a as col from t1, t2 order by a" should return an error if both tables contain field a.
-
- 09 Sep, 2004 1 commit
-
-
monty@mysql.com authored
Fixed (together with Guilhem) bugs in mysqlbinlog regarding --offset Prefix addresses with 0x for easier comparisons of debug logs Fixed problem where MySQL choosed index-read even if there would be a much better range on the same index This fix changed some 'index' queries to 'range' queries in the test suite Don't create 'dummy' WHERE clause for trivial WHERE clauses where we can remove the WHERE clause. This fix removed of a lot of 'Using where' notes in the test suite. Give NOTE instead of WARNING if table/function doesn't exists when using DROP IF EXISTS Give NOTE instead of WARNING for safe field-type conversions
-
- 07 Sep, 2004 1 commit
-
-
ram@gw.mysql.r18.ru authored
-
- 20 Aug, 2004 1 commit
-
-
dlenev@brandersnatch.localdomain authored
When in find_item_in_list() we are looking for item we should take into account unaliased names of the fields but only if item with such aliased name is not found. Also we should ignore aliases when looking for fully specified field.
-
- 22 Jun, 2004 1 commit
-
-
sergefp@mysql.com authored
If cost(full_scan_on_shortest_covering_index) < cost(best_range_scan) < cost(full_table_scan) use full_scan_on_shortest_covering_index (before this fix best_range_scan was used)
-
- 17 May, 2004 1 commit
-
-
serg@serg.mylan authored
check for field_name (not only for name) in find_item_in_list, to be compatible with item->eq() that is done later
-
- 15 May, 2004 1 commit
-
-
serg@serg.mylan authored
-
- 29 Mar, 2004 1 commit
-
-
monty@mysql.com authored
Fixes after last merge
-
- 26 Mar, 2004 1 commit
-
-
Sinisa@sinisa.nasamreza.org authored
result of the test case for FORCE INDEX on ORDER BY order_by.test: test case for FORCE INDEX on ORDER BY sql_select.cc: Changing behaviour that MySQL server takes FORCE INDEX clause into account when optimising ORDER BY clause
-
- 17 Mar, 2004 1 commit
-
-
ram@gw.mysql.r18.ru authored
Added test case for the bug #3155: strange results with index (x, y) ... WHERE x=val_1 AND y>=val_2 ORDER BY pk; (thankee Monty)
-
- 16 Feb, 2004 1 commit
-
-
monty@mysql.com authored
Added more DBUG statements Ensure that we are comparing end space with BINARY strings Use 'any_db' instead of '' to mean any database. (For HANDLER command) Only strip ' ' when comparing CHAR, not other space-like characters (like \t)
-
- 31 Jan, 2004 1 commit
-
-
ram@gw.mysql.r18.ru authored
null_ref_key moved to TABLE_REF. new null range created if necessary.
-
- 21 Dec, 2003 1 commit
-
-
monty@mysql.com authored
Fixed bug in ORDER BY on a small column (Bug #2147) Fixed error from pthread_mutex_destroy() when one had wrong errmsg file
-