- 17 Oct, 2006 4 commits
-
-
gkodinov/kgeorge@macbook.gmz authored
into macbook.gmz:/Users/kgeorge/mysql/work/B21798-5.0-opt-merge
-
gkodinov/kgeorge@macbook.gmz authored
list using a function When executing dependent subqueries they are re-inited and re-exec() for each row of the outer context. The cause for the bug is that during subquery reinitialization/re-execution, the optimizer reallocates JOIN::join_tab, JOIN::table in make_simple_join() and the local variable in 'sortorder' in create_sort_index(), which is allocated by make_unireg_sortorder(). Care must be taken not to allocate anything into the thread's memory pool while re-initializing query plan structures between subquery re-executions. All such items mush be cached and reused because the thread's memory pool is freed at the end of the whole query. Note that they must be cached and reused even for queries that are not otherwise cacheable because otherwise it will grow the thread's memory pool every time a cacheable query is re-executed. We provide additional members to the JOIN structure to store references to the items that need to be cached.
-
gkodinov/kgeorge@macbook.gmz authored
-
gkodinov/kgeorge@macbook.gmz authored
into macbook.gmz:/Users/kgeorge/mysql/work/B22367-5.0-opt-merge
-
- 16 Oct, 2006 7 commits
-
-
gkodinov/kgeorge@rakia.(none) authored
into rakia.(none):/home/kgeorge/mysql/autopush/B22342-5.0-opt
-
gkodinov/kgeorge@macbook.gmz authored
When using index for group by and range access the server isolates a set of ranges based on the conditions over the key parts of the index used. Then it uses only the ranges over the GROUP BY fields to jump from one group to another. Since the GROUP BY fields may form a prefix over the index, we may use only a prefix of the ranges produced by the range optimizer. Each range contains a notion on whether it includes its border values. The problem is that when using a range prefix, the last range is open because it assumes that there is a range on the next keypart. Thus when we use a prefix range as it is, it excludes all border values. The solution is when ignoring the suffix of the range conditions (to jump over the GROUP BY prefix only) the server must change the remaining intervals so they always contain their borders, e.g. if the whole range was : (1,-inf) <= (<group_by_col>,<min_max_arg_col>) < (1, 3) we must make (1) <= (<group_by_col>) <= (1) because (a,b) < (c1,c2) means : a < c1 OR (a = c1 AND b < c2).
-
gkodinov/kgeorge@macbook.gmz authored
strings MySQL is setting the flag HA_END_SPACE_KEYS for all the keys that reference text or varchar columns with collation different than binary. This was done to handle correctly the situation where a lookup on such a key may return more than 1 row because of the presence of many rows that differ only by the amount of trailing space in the table's string column. Inserting such values however appears to violate the unique checks on INSERT/UPDATE. Thus that flag must not be set as it will prevent the optimizer from choosing a faster access method. This fix removes the setting of the HA_END_SPACE_KEYS flag.
-
gkodinov/kgeorge@macbook.gmz authored
into macbook.gmz:/Users/kgeorge/mysql/work/B14019-5.0-opt
-
gkodinov/kgeorge@macbook.gmz authored
-
gkodinov/kgeorge@macbook.gmz authored
into macbook.gmz:/Users/kgeorge/mysql/work/B14019-5.0-opt
-
gkodinov/kgeorge@macbook.gmz authored
When resolving unqualified name references MySQL was not checking what is the item type for the reference. Thus e.g a string literal item that has by convention a name equal to its string value will also work as a reference to a SELECT list item or a table field. Fixed by allowing only Item_ref or Item_field to referenced by (unqualified) name.
-
- 13 Oct, 2006 1 commit
-
-
evgen@moonbone.local authored
The mysql_alter_table() was able to rename only a table. The view/table renaming code is moved from the function rename_tables to the new function called do_rename(). The mysql_alter_table() function calls it when it needs to rename a view.
-
- 11 Oct, 2006 1 commit
-
-
evgen@moonbone.local authored
The Cached_item_decimal::cmp() method wasn't checking for null pointer returned from the val_decimal() of the item being cached. This leads to server crash. The Cached_item_decimal::cmp() method now check for null values.
-
- 09 Oct, 2006 2 commits
-
-
gkodinov/kgeorge@macbook.local authored
into macbook.local:/Users/kgeorge/mysql/work/B22781-5.0-opt
-
gkodinov/kgeorge@macbook.local authored
Currently SQL_BIG_RESULT is checked only at compile time. However, additional optimizations may take place after this check that change the sort method from 'filesort' to sorting via index. As a result the actual plan executed is not the one specified by the SQL_BIG_RESULT hint. Similarly, there is no such test when executing EXPLAIN, resulting in incorrect output. The patch corrects the problem by testing for SQL_BIG_RESULT both during the explain and execution phases.
-
- 01 Oct, 2006 3 commits
-
-
holyfoot/hf@mysql.com/deer.(none) authored
into mysql.com:/home/hf/work/16813/my50-16813
-
holyfoot/hf@mysql.com/deer.(none) authored
into mysql.com:/home/hf/work/16813/my50-16813
-
holyfoot/hf@mysql.com/deer.(none) authored
into mysql.com:/home/hf/work/21888/my50-21888
-
- 29 Sep, 2006 7 commits
-
-
igor@rurik.mysql.com authored
into rurik.mysql.com:/home/igor/mysql-5.0-opt
-
evgen@moonbone.local authored
into moonbone.local:/work/20503-bug-5.0-mysql
-
igor@rurik.mysql.com authored
into rurik.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug22753
-
igor@rurik.mysql.com authored
After the patch for big 21698 equality propagation stopped working for BETWEEN and IN predicates with STRING arguments. This changeset completes the solution of the above patch.
-
holyfoot/hf@mysql.com/deer.(none) authored
into mysql.com:/home/hf/work/21888/my50-21888
-
holyfoot/hf@mysql.com/deer.(none) authored
RTree keys are really different from BTree and need specific paramters to be set by optimizer to work. Sometimes optimizer doesn't set those properly. Here we decided just to add code to check that the parameters are correct. Hope to fix optimizer sometimes.
-
holyfoot/hf@mysql.com/deer.(none) authored
We use the condition from CHECK OPTION twice handling UPDATE command. First we construnct 'update_cond' AND 'option_cond' condition to select records to be updated, then we check the 'option_cond' for the updated row. The problem is that first 'AND' condition is optimized during the 'select' which can break 'option_cond' structure, so it will be unusable for the sectond use - to check the updated row. Possible soultion is either use copy of the condition in the first use or to make optimization less traumatic for the operands. I picked the first one.
-
- 28 Sep, 2006 7 commits
-
-
evgen@moonbone.local authored
After merge fix
-
evgen@moonbone.local authored
into moonbone.local:/work/5505-bug-5.0-opt-mysql
-
evgen@moonbone.local authored
On an INSERT into an updatable but non-insertable view an error message was issued stating the view being not updatable. This can lead to a confusion of a user. A new error message is introduced. Is is showed when a user tries to insert into a non-insertable view.
-
evgen@moonbone.local authored
while space allocation Under some circumstances DISTINCT clause can be converted to grouping. In such cases grouping is performed by all items in the select list. If an ORDER clause is present then items from it is prepended to group list. But the case with ORDER wasn't taken into account when allocating the array for sum functions. This leads to memory corruption and crash. The JOIN::alloc_func_list() function now allocates additional space if there is an ORDER by clause is specified and DISTINCT -> GROUP BY optimization is possible.
-
gkodinov@dl145s.mysql.com authored
into dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.0-opt
-
gkodinov@dl145s.mysql.com authored
into dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.0-opt
-
gkodinov@dl145s.mysql.com authored
into dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-4.1-opt
-
- 27 Sep, 2006 7 commits
-
-
gluh@mysql.com/gluh.(none) authored
-
gluh@mysql.com/gluh.(none) authored
-
gluh@mysql.com/gluh.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.0
-
gluh@mysql.com/gluh.(none) authored
-
gkodinov/kgeorge@macbook.gmz authored
- reversed the patch for 5.0 and moved to 5.1
-
holyfoot/hf@mysql.com/deer.(none) authored
into mysql.com:/home/hf/work/mysql-5.0-mrg
-
holyfoot/hf@mysql.com/deer.(none) authored
into mysql.com:/home/hf/work/mysql-4.1.15428
-
- 26 Sep, 2006 1 commit
-
-
joerg@trift2. authored
into trift2.:/MySQL/M50/push-5.0
-