- 29 Jun, 2006 2 commits
-
-
gkodinov@mysql.com authored
into mysql.com:/home/kgeorge/mysql/5.0/warnings
-
gkodinov@mysql.com authored
into mysql.com:/home/kgeorge/mysql/4.1/warnings
-
- 28 Jun, 2006 2 commits
-
-
gkodinov@mysql.com authored
-
gkodinov@mysql.com authored
-
- 27 Jun, 2006 3 commits
-
-
gkodinov@mysql.com authored
into mysql.com:/home/kgeorge/mysql/4.1/B16458
-
gkodinov@mysql.com authored
into mysql.com:/home/kgeorge/mysql/5.0/B16458
-
gkodinov@mysql.com authored
'SELECT DISTINCT a,b FROM t1' should not use temp table if there is unique index (or primary key) on a. There are a number of other similar cases that can be calculated without the use of a temp table : multi-part unique indexes, primary keys or using GROUP BY instead of DISTINCT. When a GROUP BY/DISTINCT clause contains all key parts of a unique index, then it is guaranteed that the fields of the clause will be unique, therefore we can optimize away GROUP BY/DISTINCT altogether. This optimization has two effects: * there is no need to create a temporary table to compute the GROUP/DISTINCT operation (or the temporary table will be smaller if only GROUP is removed and DISTINCT stays or if DISTINCT is removed and GROUP BY stays) * this causes the statement in effect to become updatable in Connector/Java because the result set columns will be direct reference to the primary key of the table (instead to the temporary table that it currently references). Implemented a check that will optimize away GROUP BY/DISTINCT for queries like the above. Currently it will work only for single non-constant table in the FROM clause.
-
- 23 Jun, 2006 2 commits
-
-
igor@rurik.mysql.com authored
into rurik.mysql.com:/home/igor/mysql-5.0-opt
-
igor@rurik.mysql.com authored
This was another manifestation of the problems fixed in the patch for bug 16674. Wrong calculation of length of the search prefix in the pattern string led here to a wrong result set for a query in 4.1. The bug could be demonstrated for any multi-byte character set.
-
- 22 Jun, 2006 6 commits
-
-
igor@rurik.mysql.com authored
into rurik.mysql.com:/home/igor/mysql-5.0-opt
-
igor@rurik.mysql.com authored
Server crashed in some cases when a query required a MIN/MAX agrregation for a 'ucs2' field. In these cases the aggregation caused calls of the function update_tmptable_sum_func that indirectly invoked the method Item_sum_hybrid::min_max_update_str_field() containing a call to strip_sp for a ucs2 character set. The latter led directly to the crash as it used my_isspace undefined for the ucs2 character set. Actually the call of strip_sp is not needed at all in this situation and has been removed by the fix.
-
igor@rurik.mysql.com authored
-
igor@rurik.mysql.com authored
into rurik.mysql.com:/home/igor/mysql-5.0-opt
-
igor@rurik.mysql.com authored
execution plans in 4.1 and 5.0.
-
igor@rurik.mysql.com authored
into rurik.mysql.com:/home/igor/mysql-5.0-opt
-
- 21 Jun, 2006 25 commits
-
-
igor@rurik.mysql.com authored
into rurik.mysql.com:/home/igor/mysql-4.1-opt
-
evgen@moonbone.local authored
into moonbone.local:/work/tmp_merge-5.0-opt-mysql
-
evgen@moonbone.local authored
-
evgen@moonbone.local authored
into moonbone.local:/work/tmp_merge-5.0-opt-mysql
-
evgen@moonbone.local authored
into moonbone.local:/work/tmp_merge-4.1-opt-mysql
-
evgen@moonbone.local authored
This bug in Field_string::cmp resulted in a wrong comparison with keys in partial indexes over multi-byte character fields. Given field a is declared as a varchar(16) collate utf8_unicode_ci INDEX(a(4)) gives us an example of such an index. Wrong key comparisons could lead to wrong result sets if the selected query execution plan used a range scan by a partial index over a utf8 character field. This also caused wrong results in many other cases.
-
mats@mysql.com authored
into mysql.com:/home/bk/fix-mysql-5.0
-
svoj@may.pils.ru authored
into may.pils.ru:/home/svoj/devel/mysql/BUG20357/mysql-5.0
-
svoj@may.pils.ru authored
into may.pils.ru:/home/svoj/devel/mysql/BUG20357/mysql-4.1
-
tomas@poseidon.ndb.mysql.com authored
-
svoj@may.pils.ru authored
into may.pils.ru:/home/svoj/devel/mysql/BUG20357/mysql-4.1
-
svoj@may.pils.ru authored
functions in queries Using MAX()/MIN() on table with disabled indexes (by ALTER TABLE) results in error 124 (wrong index) from storage engine. The problem was that optimizer use disabled index to optimize MAX()/MIN(). Normally it must skip disabled index and perform table scan. This patch skips disabled indexes for min/max optimization.
-
knielsen@mysql.com authored
into mysql.com:/data0/knielsen/mysql-5.0
-
knielsen@mysql.com authored
Backport Valgrind suppression from mysql-5.1: D 1.4 05/11/23 22:44:54+02:00 monty@mysql.com 5 4 12/0/154 P mysql-test/valgrind.supp C Remove warning that may happens becasue threads dies in different order
-
joerg@mysql.com authored
-
gkodinov@mysql.com authored
into mysql.com:/home/kgeorge/mysql/5.0/B18080
-
mskold@mysql.com authored
into mysql.com:/home/marty/MySQL/mysql-5.0
-
tomas@poseidon.ndb.mysql.com authored
into poseidon.ndb.mysql.com:/home/tomas/mysql-5.0-main
-
gkodinov@mysql.com authored
-
gkodinov@mysql.com authored
-
gkodinov@mysql.com authored
into mysql.com:/home/kgeorge/mysql/5.0/B20482
-
gkodinov@mysql.com authored
schemas The function check_one_table_access() called to check access to tables in SELECT/INSERT/UPDATE was doing additional checks/modifications that don't hold in the context of setup_tables_and_check_access(). That's why the check_one_table() was split into two : the functionality needed by setup_tables_and_check_access() into check_single_table_access() and the rest of the functionality stays in check_one_table_access() that is made to call the new check_single_table_access() function.
-
mskold@mysql.com authored
into mysql.com:/home/marty/MySQL/mysql-5.0
-
mskold@mysql.com authored
-
tomas@poseidon.ndb.mysql.com authored
into poseidon.ndb.mysql.com:/home/tomas/mysql-5.0-main
-