- 16 Nov, 2006 1 commit
-
-
holyfoot/hf@mysql.com/deer.(none) authored
In fact the problem is inside the ARCHIVE engine. It stores real datapath inside the ARM file, but doesn't implement specific ha_archive::rename_table function. As the ALTER TABLE statement first creates the table with the temporary name and then renames it to the normal one, we get the temporary name saved in ARM what leads to "can't open file" error. Code modified to store only path in the ARM, without filename.
-
- 10 Nov, 2006 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
-
- 09 Nov, 2006 5 commits
-
-
holyfoot/hf@deer.(none) authored
into mysql.com:/home/hf/work/8663/my51-8663
-
gkodinov/kgeorge@macbook.gmz authored
into macbook.gmz:/Users/kgeorge/mysql/work/mem-test-5.1-opt
-
holyfoot/hf@mysql.com/deer.(none) authored
-
holyfoot/hf@mysql.com/deer.(none) authored
-
holyfoot/hf@mysql.com/deer.(none) authored
-
- 08 Nov, 2006 5 commits
-
-
holyfoot/hf@mysql.com/deer.(none) authored
-
holyfoot/hf@deer.(none) authored
into mysql.com:/home/hf/work/mysql-5.1.clean
-
gkodinov/kgeorge@macbook.gmz authored
into macbook.gmz:/Users/kgeorge/mysql/work/mem-test-5.0-opt
-
gkodinov/kgeorge@macbook.gmz authored
-
sergefp@mysql.com authored
into mysql.com:/home/psergey/mysql-5.0-bug8804-pfix
-
- 07 Nov, 2006 8 commits
-
-
sergefp@mysql.com authored
Don't assume that condition that was pushed down into subquery has produced exactly one KEY_FIELD element - it could produce several or none at all, handle all of those cases.
-
gkodinov/kgeorge@rakia.gmz authored
into rakia.gmz:/home/kgeorge/mysql/autopush/B11032-5.0-opt
-
holyfoot/hf@mysql.com/deer.(none) authored
into mysql.com:/home/hf/work/mysql-5.0.clean
-
holyfoot/hf@mysql.com/deer.(none) authored
-
gkodinov/kgeorge@macbook.gmz authored
into macbook.gmz:/Users/kgeorge/mysql/work/B11032-5.0-opt
-
gkodinov/kgeorge@macbook.gmz authored
- When returning metadata for scalar subqueries the actual type of the column was calculated based on the value type, which limits the actual type of a scalar subselect to the set of (currently) 3 basic types : integer, double precision or string. This is the reason that columns of types other then the basic ones (e.g. date/time) are reported as being of the corresponding basic type. Fixed by storing/returning information for the column type in addition to the result type.
-
gkodinov@dl145s.mysql.com authored
merge fixes
-
gkodinov@dl145s.mysql.com authored
into dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.0-opt
-
- 06 Nov, 2006 6 commits
-
-
holyfoot/hf@mysql.com/deer.(none) authored
-
holyfoot/hf@deer.(none) authored
into mysql.com:/home/hf/work/8663/my51-8663
-
holyfoot/hf@mysql.com/deer.(none) authored
into mysql.com:/home/hf/work/21790/my50-21790
-
holyfoot/hf@mysql.com/deer.(none) authored
into mysql.com:/home/hf/work/19491/my50-19491
-
holyfoot/hf@deer.(none) authored
into mysql.com:/home/hf/work/8663/my51-8663
-
holyfoot/hf@deer.(none) authored
into mysql.com:/home/hf/work/8663/my51-8663
-
- 05 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.
-
- 01 Nov, 2006 6 commits
-
-
igor@rurik.mysql.com authored
into rurik.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug21727
-
holyfoot/hf@deer.(none) authored
into mysql.com:/home/hf/work/21790/my51-21790
-
holyfoot/hf@deer.(none) authored
into mysql.com:/home/hf/work/21790/my51-21790
-
holyfoot/hf@mysql.com/deer.(none) authored
into mysql.com:/home/hf/work/mysql-5.0.19491
-
holyfoot/hf@mysql.com/deer.(none) authored
-
igor@rurik.mysql.com authored
This is a performance issue for queries with subqueries evaluation of which requires filesort. Allocation of memory for the sort buffer at each evaluation of a subquery may take a significant amount of time if the buffer is rather big. With the fix we allocate the buffer at the first evaluation of the subquery and reuse it at each subsequent evaluation.
-
- 31 Oct, 2006 6 commits
-
-
sergefp@mysql.com authored
into mysql.com:/home/psergey/mysql-5.0-bug8804-r4
-
sergefp@mysql.com authored
- Better comments - Remove redundant and dead code.
-
sergefp@mysql.com authored
the fix.
-
sergefp@mysql.com authored
Evaluate "NULL IN (SELECT ...)" in a special way: Disable pushed-down conditions and their "consequences": = Do full table scans instead of unique_[index_subquery] lookups. = Change appropriate "ref_or_null" accesses to full table scans in subquery's joins. Also cache value of NULL IN (SELECT ...) if the SELECT is not correlated wrt any upper select.
-
into mysql.com:/usersnfs/abotchkov/mysql-5.0-opt1
-
gkodinov/kgeorge@rakia.gmz authored
into rakia.gmz:/home/kgeorge/mysql/autopush/B21809-5.0-opt
-