- 13 Nov, 2006 5 commits
-
-
holyfoot/hf@mysql.com/deer.(none) authored
-
holyfoot/hf@mysql.com/deer.(none) authored
into mysql.com:/home/hf/work/embt/my50-embt
-
holyfoot/hf@mysql.com/deer.(none) authored
-
holyfoot/hf@mysql.com/deer.(none) authored
into mysql.com:/home/hf/work/embt/my50-embt
-
holyfoot/hf@mysql.com/deer.(none) authored
-
- 08 Nov, 2006 3 commits
-
-
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 3 commits
-
-
holyfoot/hf@mysql.com/deer.(none) authored
-
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
-
- 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 4 commits
-
-
igor@rurik.mysql.com authored
into rurik.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug21727
-
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 8 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
-
gkodinov/kgeorge@rakia.gmz authored
into rakia.gmz:/home/kgeorge/mysql/autopush/B23184-5.0-opt
-
gkodinov/kgeorge@macbook.gmz authored
Item::val_xxx() may be called by the server several times at execute time for a single query. Calls to val_xxx() may be very expensive and sometimes (count(distinct), sum(distinct), avg(distinct)) not possible. To avoid that problem the results of calculation for these aggregate functions are cached so that val_xxx() methods just return the calculated value for the second and subsequent calls.
-
- 25 Oct, 2006 1 commit
-
-
holyfoot/hf@mysql.com/deer.(none) authored
-
- 24 Oct, 2006 7 commits
-
-
into mysql.com:/usersnfs/abotchkov/mysql-4.1-opt1
-
into mysql.com:/usersnfs/abotchkov/mysql-5.0-opt1
-
holyfoot/hf@mysql.com/deer.(none) authored
into mysql.com:/home/hf/work/current_stmt/my50-current_stmt
-
holyfoot/hf@mysql.com/deer.(none) authored
into mysql.com:/home/hf/work/0current_stmt/my41-current_stmt
-
holyfoot/hf@mysql.com/deer.(none) authored
into mysql.com:/home/hf/work/current_stmt/my50-current_stmt
-
gkodinov/kgeorge@macbook.gmz authored
select OK. The SQL parser was using Item::name to transfer user defined function attributes to the user defined function (udf). It was not distinguishing between user defined function call arguments and stored procedure call arguments. Setting Item::name was causing Item_ref::print() method to print the argument as quoted identifiers and caused views that reference aggregate functions as udf call arguments (and rely on Item::print() for the text of the view to store) to throw an undefined identifier error. Overloaded Item_ref::print to print aggregate functions as such when printing the references to aggregate functions taken out of context by split_sum_func2() Fixed the parser to properly detect using AS clause in stored procedure arguments as an error. Fixed printing the arguments of udf call to print properly the udf attribute.
-
holyfoot/hf@mysql.com/deer.(none) authored
the incompatibility was caused by current_stmt member added to the MYSQL structure. It's possible to move it to THD structure instead which saves ABI
-