- 10 May, 2006 4 commits
-
-
sergefp@mysql.com authored
Re-work best_access_path() and find_best() to reuse E(#rows(range access)) as E(#rows(ref[_or_null](const) access) only when it is appropriate. [This is the final cumulative patch]
-
gkodinov@mysql.com authored
into mysql.com:/home/kgeorge/mysql/5.0/B18068
-
sergefp@mysql.com authored
into mysql.com:/home/psergey/mysql-5.0-best_access_path_j-push
-
sergefp@mysql.com authored
into mysql.com:/home/psergey/mysql-5.0-best_access_path_j-push
-
- 09 May, 2006 9 commits
-
-
acurtis@xiphis.org authored
into xiphis.org:/home/antony/work2/mysql-5.0-engines-merge
-
acurtis@xiphis.org authored
into xiphis.org:/home/antony/work2/p1-bug10952.1
-
acurtis@xiphis.org authored
"alter table from MyISAM to MERGE lost data without errors and warnings" Add new handlerton flag which prevent user from altering table storage engine to storage engines which would lose data. Both 'blackhole' and 'merge' are marked with the new flag. Tests included.
-
gkodinov@mysql.com authored
When converting DISTINCT to GROUP BY where the columns are from the covering index and they are quoted twice in the SELECT list the optimizer is creating improper processing sequence. This is because of the fact that the columns of the covering index are not recognized as such and treated as non-index columns. Generally speaking duplicate columns can safely be removed from the GROUP BY/DISTINCT list because this will not add or remove new rows in the resulting set. Duplicates can be removed even if they are not consecutive (as is the case for ORDER BY, where the duplicate columns can be removed only if they are consecutive). So we can safely transform "SELECT DISTINCT a,a FROM ... ORDER BY a" to "SELECT a,a FROM ... GROUP BY a ORDER BY a" instead of "SELECT a,a FROM .. GROUP BY a,a ORDER BY a". We can even transform "SELECT DISTINCT a,b,a FROM ... ORDER BY a,b" to "SELECT a,b,a FROM ... GROUP BY a,b ORDER BY a,b". The fix to this bug consists of checking for duplicate columns in the SELECT list when constructing the GROUP BY list in transforming DISTINCT to GROUP BY and skipping the ones that are already in.
-
mskold@mysql.com authored
into mysql.com:/home/marty/MySQL/mysql-5.0
-
mskold@mysql.com authored
into mysql.com:/home/marty/MySQL/mysql-5.0
-
mskold@mysql.com authored
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0-maint
-
- 08 May, 2006 5 commits
-
-
kent@mysql.com authored
No commit message
-
kent@mysql.com authored
into mysql.com:/Users/kent/mysql/bk/mysql-5.0-new
-
msvensson@neptunus.(none) authored
Add function 'vio_end' that will cleanup resources allocated by vio and the components it uses.
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0-maint
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0-maint
-
- 07 May, 2006 11 commits
-
-
igor@rurik.mysql.com authored
into rurik.mysql.com:/home/igor/mysql-5.0
-
igor@rurik.mysql.com authored
-
igor@rurik.mysql.com authored
into rurik.mysql.com:/home/igor/dev/mysql-5.0-0
-
igor@rurik.mysql.com authored
into rurik.mysql.com:/home/igor/mysql-4.1
-
aelkin@mysql.com authored
into mysql.com:/usr_rh9/home/elkin.rh9/MySQL/Merge/5.0-bug19136
-
aelkin@mysql.com authored
recalculating results
-
sergefp@mysql.com authored
-
sergefp@mysql.com authored
find_best() call best_access_path().
-
aelkin@mysql.com authored
into mysql.com:/usr_rh9/home/elkin.rh9/MySQL/Merge/5.0-bug19136
-
aelkin@mysql.com authored
into mysql.com:/usr_rh9/home/elkin.rh9/MySQL/FIXES/4.1-bug19136_unass_user_var
-
igor@rurik.mysql.com authored
A query with a group by and having clauses could return a wrong result set if the having condition contained a constant conjunct evaluated to FALSE. It happened because the pushdown condition for table with grouping columns lost its constant conjuncts. Pushdown conditions are always built by the function make_cond_for_table that ignores constant conjuncts. This is apparently not correct when constant false conjuncts are present.
-
- 06 May, 2006 11 commits
-
-
sergefp@mysql.com authored
into mysql.com:/home/psergey/mysql-5.0-bug16798-merge
-
sergefp@mysql.com authored
into mysql.com:/home/psergey/mysql-4.1-bug16798
-
kroki@mysql.com authored
into mysql.com:/home/tomash/src/mysql_ab/mysql-5.0-merge
-
kroki@mysql.com authored
into mysql.com:/home/tomash/src/mysql_ab/mysql-4.1-bug16501
-
kroki@mysql.com authored
into mysql.com:/home/tomash/src/mysql_ab/mysql-4.1-bug16501
-
kroki@mysql.com authored
-
ingo@mysql.com authored
into mysql.com:/home/mydev/mysql-4.1-bug10405
-
ingo@mysql.com authored
into mysql.com:/home/mydev/mysql-5.0-bug10405
-
sergefp@mysql.com authored
into mysql.com:/home/psergey/mysql-4.1-bug16798
-
sergefp@mysql.com authored
into mysql.com:/home/psergey/mysql-5.0-bug16798-merge
-
sergefp@mysql.com authored
The bug was as follows: When merge_key_fields() encounters "t.key=X OR t.key=Y" it will try to join them into ref_or_null access via "t.key=X OR NULL". In order to make this inference it checks if Y<=>NULL, ignoring the fact that value of Y may be not yet known. The fix is that the check if Y<=>NULL is made only if value of Y is known (i.e. it is a constant). TODO: When merging to 5.0, replace used_tables() with const_item() everywhere in merge_key_fields().
-