An error occurred fetching the project authors.
- 16 Sep, 2010 1 commit
-
-
Sergey Glukhov authored
Subselect executes twice, at JOIN::optimize stage and at JOIN::execute stage. At optimize stage Innodb prebuilt struct which is used for the retrieval of column values is initialized in. ha_innobase::index_read(), prebuilt->sql_stat_start is true. After QUICK_ROR_INTERSECT_SELECT finished his job it restores read_set/write_set bitmaps with initial values and deactivates one of the handlers used by QUICK_ROR_INTERSECT_SELECT in JOIN::cleanup (it's the case when we reuse original handler as one of handlers required by QUICK_ROR_INTERSECT_SELECT object). On second subselect execution inactive handler is activated in QUICK_RANGE_SELECT::reset, file->ha_index_init(). In ha_index_init Innodb prebuilt struct is reinitialized with inappropriate read_set/write_set bitmaps. Further reinitialization in ha_innobase::index_read() does not happen as prebuilt->sql_stat_start is false. It leads to partial retrieval of required field values and we get a mix of field values from different records in the record buffer. The fix is to reset read_set/write_set bitmaps as these values are required for proper intialization of internal InnoDB struct which is used for the retrieval of column values (see build_template(), ha_innodb.cc) mysql-test/include/index_merge_ror_cpk.inc: test case mysql-test/r/index_merge_innodb.result: test case mysql-test/r/index_merge_myisam.result: test case sql/opt_range.cc: if ROR merge scan is used we need to reset read_set/write_set bitmaps as these values are required for proper intialization of internal InnoDB struct which is used for the retrieval of column values (see build_template(), ha_innodb.cc)
-
- 24 Aug, 2010 1 commit
-
-
Alexey Kopytov authored
Queries involving predicates of the form "const NOT BETWEEN not_indexed_column AND indexed_column" could return wrong data due to incorrect handling by the range optimizer. For "c NOT BETWEEN f1 AND f2" predicates, get_mm_tree() produces a disjunction of the SEL_ARG trees for "f1 > c" and "f2 < c". If one of the trees is empty (i.e. one of the arguments is not sargable) the resulting tree should be empty as well, since the whole expression in this case is not sargable. The above logic is implemented in get_mm_tree() as follows. The initial state of the resulting tree is NULL (aka empty). We then iterate through arguments and compute the corresponding SEL_ARG tree (either "f1 > c" or "f2 < c"). If the resulting tree is NULL, it is simply replaced by the generated tree. Otherwise it is replaced by a disjunction of itself and the generated tree. The obvious flaw in this implementation is that if the first argument is not sargable and thus produces a NULL tree, the resulting tree will simply be replaced by the tree for the second argument. As a result, "c NOT BETWEEN f1 AND f2" will end up as just "f2 < c". Fixed by adding a check so that when the first argument produces an empty tree for the NOT BETWEEN case, the loop is aborted with an empty tree as a result. The whole idea of using a loop for 2 arguments does not make much sense, but it was probably used to avoid code duplication for several BETWEEN variants.
-
- 15 Jul, 2010 1 commit
-
-
Alexey Kopytov authored
Calculating the estimated number of records for a range scan may take a significant time, and it was impossible for a user to interrupt that process by killing the connection or the query. Fixed by checking the thread's 'killed' status in check_quick_keys() and interrupting the calculation process if it is set to a non-zero value.
-
- 24 Jun, 2010 1 commit
-
-
Martin Hansson authored
require O(#scans) memory When an index merge operation was restarted, it would re-allocate the Unique object controlling the duplicate row ID elimination. Fixed by making the Unique object a member of QUICK_INDEX_MERGE_SELECT and thus reusing it throughout the lifetime of this object.
-
- 21 Jun, 2010 1 commit
-
-
Sergey Glukhov authored
In process of record search it is not taken into account that inital quick->file->ref value could be inapplicable to range interval. After proper row is found this value is stored into the record buffer and later the record is filtered out at condition evaluation stage. The fix is store a refernce of found row to the handler ref field. mysql-test/r/innodb_mysql.result: test case mysql-test/std_data/intersect-bug50389.tsv: test case mysql-test/t/innodb_mysql.test: test case sql/opt_range.cc: store a refernce of found row to the handler ref field.
-
- 10 May, 2010 1 commit
-
-
Martin Hansson authored
remember range endpoints The Loose Index Scan optimization keeps track of a sequence of intervals. For the current interval it maintains the current interval's endpoints. But the maximum endpoint was not stored in the SQL layer; rather, it relied on the storage engine to retain this value in-between reads. By coincidence this holds for MyISAM and InnoDB. Not for the partitioning engine, however. Fixed by making the key values iterator (QUICK_RANGE_SELECT) keep track of the current maximum endpoint. This is also more efficient as we save a call through the handler API in case of open-ended intervals. The code to calculate endpoints was extracted into separate methods in QUICK_RANGE_SELECT, and it was possible to get rid of some code duplication as part of fix.
-
- 09 Feb, 2010 1 commit
-
-
Sergey Vojtovich authored
Queries optimized with GROUP_MIN_MAX didn't cleanup KEYREAD optimization properly. As a result subsequent queries may return incomplete rows (fields are initialized to default values). mysql-test/r/group_min_max.result: A test case for BUG#49902. mysql-test/t/group_min_max.test: A test case for BUG#49902. sql/opt_range.cc: Refactor of KEYREAD optimization switch so that KEYREAD handler state is in sync with st_table::key_read flag. All SQL code is supposed to switch KEYREAD optimization via st_table::set_keyread(). sql/opt_sum.cc: Refactor of KEYREAD optimization switch so that KEYREAD handler state is in sync with st_table::key_read flag. All SQL code is supposed to switch KEYREAD optimization via st_table::set_keyread(). sql/sql_select.cc: Refactor of KEYREAD optimization switch so that KEYREAD handler state is in sync with st_table::key_read flag. All SQL code is supposed to switch KEYREAD optimization via st_table::set_keyread(). sql/sql_update.cc: Refactor of KEYREAD optimization switch so that KEYREAD handler state is in sync with st_table::key_read flag. All SQL code is supposed to switch KEYREAD optimization via st_table::set_keyread(). sql/table.cc: Refactor of KEYREAD optimization switch so that KEYREAD handler state is in sync with st_table::key_read flag. All SQL code is supposed to switch KEYREAD optimization via st_table::set_keyread(). sql/table.h: Refactor of KEYREAD optimization switch so that KEYREAD handler state is in sync with st_table::key_read flag. All SQL code is supposed to switch KEYREAD optimization via st_table::set_keyread().
-
- 03 Feb, 2010 1 commit
-
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 2818.1.5 > revision-id: ramil@mysql.com-20091023112648-gie6o3odj57cxh1e > parent: ramil@mysql.com-20091021090408-208mvwwrcroi2j8c > committer: Ramil Kalimullin <ramil@mysql.com> > branch nick: b48258-5.0-bugteam > timestamp: Fri 2009-10-23 16:26:48 +0500 > message: > Fix for bug#48258: Assertion failed when using a spatial index > > Problem: involving a spatial index for "non-spatial" queries > (that don't containt MBRXXX() functions) may lead to failed assert. > > Fix: don't use spatial indexes in such cases.
-
- 25 Nov, 2009 4 commits
-
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 3181 > revision-id: alexey.kopytov@sun.com-20091016201951-fsht0wm8xn8vkzsx > parent: joerg@mysql.com-20091016164025-kb4sbrggq5o7zufc > committer: Alexey Kopytov <Alexey.Kopytov@Sun.com> > branch nick: mysql-5.1-bugteam > timestamp: Sat 2009-10-17 00:19:51 +0400 > message: > Bug #47123: Endless 100% CPU loop with STRAIGHT_JOIN > > The problem was in incorrect handling of predicates involving > NULL as a constant value by the range optimizer. > > For example, when creating a SEL_ARG node from a condition of > the form "field < const" (which would normally result in the > "NULL < field < const" SEL_ARG), the special case when "const" > is NULL was not taken into account, so "NULL < field < NULL" > was produced for the "field < NULL" condition. > > As a result, SEL_ARG structures of this form could not be > further optimized which in turn could lead to incorrectly > constructed SEL_ARG trees. In particular, code assuming SEL_ARG > structures to always form a sequence of ordered disjoint > intervals could enter an infinite loop under some > circumstances. > > Fixed by changing get_mm_leaf() so that for any sargable > predicate except "<=>" involving NULL as a constant, "empty" > SEL_ARG is returned, since such a predicate is always false.
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 3148.9.6 > revision-id: martin.hansson@sun.com-20091102122407-krzh4h0i052lbwr5 > parent: davi.arnaut@sun.com-20091102112236-k3myix2xy8miyv4s > committer: Martin Hansson <martin.hansson@sun.com> > branch nick: 5.1bt > timestamp: Mon 2009-11-02 13:24:07 +0100 > message: > Bug#47925: regression of range optimizer and date comparison in 5.1.39! > > When a query was using a DATE or DATETIME value formatted > using any other separator characters beside hyphen '-', a > query with a greater-or-equal '>=' condition matching only > the greatest value in an indexed column, the result was > empty if index range scan was employed. > > The range optimizer got a new feature between 5.1.38 and > 5.1.39 that changes a greater-or-equal condition to a > greater-than if the value matching that in the query was not > present in the table. But the value comparison function > compared the dates as strings instead of dates. > > The bug was fixed by splitting the function > get_date_from_str in two: One part that parses and does > error checking. This function is now visible outside the > module. The old get_date_from_str now calls the new > function.
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 1810.3959.5 > revision-id: ramil@mysql.com-20091023112648-gie6o3odj57cxh1e > parent: ramil@mysql.com-20091021090408-208mvwwrcroi2j8c > committer: Ramil Kalimullin <ramil@mysql.com> > branch nick: b48258-5.0-bugteam > timestamp: Fri 2009-10-23 16:26:48 +0500 > message: > Fix for bug#48258: Assertion failed when using a spatial index > > Problem: involving a spatial index for "non-spatial" queries > (that don't containt MBRXXX() functions) may lead to failed assert. > > Fix: don't use spatial indexes in such cases.
-
Martin Hansson authored
for each record' There was an error in an internal structure in the range optimizer (SEL_ARG). Bad design causes parts of a data structure not to be initialized when it is in a certain state. All client code must check that this state is not present before trying to access the structure's data. Fixed by - Checking the state before trying to access data (in several places, most of which not covered by test case.) - Copying the keypart id when cloning SEL_ARGs mysql-test/r/range.result: Bug#48459: Test result. mysql-test/t/range.test: Bug#48459: Test case. sql/opt_range.cc: Bug#48459: Fix + doxygenated count_key_part_usage comment.
-
- 19 Nov, 2009 1 commit
-
-
Georgi Kodinov authored
When merging ranges during calculation of the result of OR to two range sets the current range may be obsoleted by the resulting merged range. The first overlapping range can be obsoleted as well. Fixed by moving the pointer to the first overlapping range to the pointer of the resulting union range. Added few comments at key places in key_or().
-
- 17 Nov, 2009 1 commit
-
-
Alexey Kopytov authored
WHERE conditions check_group_min_max() checks if the loose index scan optimization is applicable for a given WHERE condition, that is if the MIN/MAX attribute participates only in range predicates comparing the corresponding field with constants. The problem was that it considered the whole predicate suitable for the loose index scan optimization as soon as it encountered a constant as a predicate argument. This is obviously wrong for cases when a constant is the first argument of a predicate which does not satisfy the above condition. Fixed check_group_min_max() so that all arguments of the input predicate are considered to decide if it passes the test, even though a constant has already been encountered. mysql-test/r/group_min_max.result: Added a test case for bug #48472. mysql-test/t/group_min_max.test: Added a test case for bug #48472. sql/opt_range.cc: Fixed check_group_min_max() so that all arguments of the input predicate are considered to decide if it passes the test, even though a constant has already been encountered.
-
- 02 Nov, 2009 1 commit
-
-
Martin Hansson authored
When a query was using a DATE or DATETIME value formatted using any other separator characters beside hyphen '-', a query with a greater-or-equal '>=' condition matching only the greatest value in an indexed column, the result was empty if index range scan was employed. The range optimizer got a new feature between 5.1.38 and 5.1.39 that changes a greater-or-equal condition to a greater-than if the value matching that in the query was not present in the table. But the value comparison function compared the dates as strings instead of dates. The bug was fixed by splitting the function get_date_from_str in two: One part that parses and does error checking. This function is now visible outside the module. The old get_date_from_str now calls the new function. mysql-test/r/range.result: Bug#47925: Test result mysql-test/t/range.test: Bug#47925: Test case sql/item.cc: Bug#47925: Fix + some edit on the comments sql/item.h: Bug#47925: Changed function signature sql/item_cmpfunc.cc: Bug#47925: Split function in two sql/item_cmpfunc.h: Bug#47925: Declaration of new function sql/opt_range.cc: Bug#47925: Added THD to function call sql/time.cc: Bug#47925: Added microsecond comparison
-
- 23 Oct, 2009 1 commit
-
-
Ramil Kalimullin authored
Problem: involving a spatial index for "non-spatial" queries (that don't containt MBRXXX() functions) may lead to failed assert. Fix: don't use spatial indexes in such cases. mysql-test/r/gis-rtree.result: Fix for bug#48258: Assertion failed when using a spatial index - test result. mysql-test/t/gis-rtree.test: Fix for bug#48258: Assertion failed when using a spatial index - test case. sql/opt_range.cc: Fix for bug#48258: Assertion failed when using a spatial index - allow only spatial functions (MBRXXX) for itMBR keyparts.
-
- 16 Oct, 2009 2 commits
-
-
Alexey Kopytov authored
The problem was in incorrect handling of predicates involving NULL as a constant value by the range optimizer. For example, when creating a SEL_ARG node from a condition of the form "field < const" (which would normally result in the "NULL < field < const" SEL_ARG), the special case when "const" is NULL was not taken into account, so "NULL < field < NULL" was produced for the "field < NULL" condition. As a result, SEL_ARG structures of this form could not be further optimized which in turn could lead to incorrectly constructed SEL_ARG trees. In particular, code assuming SEL_ARG structures to always form a sequence of ordered disjoint intervals could enter an infinite loop under some circumstances. Fixed by changing get_mm_leaf() so that for any sargable predicate except "<=>" involving NULL as a constant, "empty" SEL_ARG is returned, since such a predicate is always false. mysql-test/r/partition_pruning.result: Fixed a broken test case. mysql-test/r/range.result: Added a test case for bug #47123. mysql-test/r/subselect.result: Fixed a broken test cases. mysql-test/t/range.test: Added a test case for bug #47123. sql/opt_range.cc: Fixed get_mm_leaf() so that for any sargable predicate except "<=>" involving NULL as a constant, "empty" SEL_ARG is returned, since such a predicate is always false.
-
Georgi Kodinov authored
-
- 13 Oct, 2009 1 commit
-
-
Alexey Kopytov authored
The problem was in incorrect handling of predicates involving NULL as a constant value by the range optimizer. For example, when creating a SEL_ARG node from a condition of the form "field < const" (which would normally result in the "NULL < field < const" SEL_ARG), the special case when "const" is NULL was not taken into account, so "NULL < field < NULL" was produced for the "field < NULL" condition. As a result, SEL_ARG structures of this form could not be further optimized which in turn could lead to incorrectly constructed SEL_ARG trees. In particular, code assuming SEL_ARG structures to always form a sequence of ordered disjoint intervals could enter an infinite loop under some circumstances. Fixed by changing get_mm_leaf() so that for any sargable predicate except "<=>" involving NULL as a constant, "empty" SEL_ARG is returned, since such a predicate is always false. mysql-test/r/range.result: Added a test case for bug #47123. mysql-test/t/range.test: Added a test case for bug #47123. sql/opt_range.cc: Fixed get_mm_leaf() so that for any sargable predicate except "<=>" involving NULL as a constant, "empty" SEL_ARG is returned, since such a predicate is always false.
-
- 09 Oct, 2009 1 commit
-
-
Martin Hansson authored
covering index When two range predicates were combined under an OR predicate, the algorithm tried to merge overlapping ranges into one. But the case when a range overlapped several other ranges was not handled. This lead to 1) ranges overlapping, which gave repeated results and 2) a range that overlapped several other ranges was cut off. Fixed by 1) Making sure that a range got an upper bound equal to the next range with a greater minimum. 2) Removing a continue statement mysql-test/r/group_min_max.result: Bug#42846: Changed query plans mysql-test/r/range.result: Bug#42846: Test result. mysql-test/t/range.test: Bug#42846: Test case. sql/opt_range.cc: Bug#42846: The fix. Part1: Previously, both endpoints from key2 were copied, which is not safe. Since ranges are processed in ascending order of minimum endpoints, it is safe to copy the minimum endpoint from key2 but not the maximum. The maximum may only be copied if there is no other range or the other range's minimum is greater than key2's maximum.
-
- 08 Oct, 2009 1 commit
-
-
Ramil Kalimullin authored
can lead to bad memory access Problem: Field_bit is the only field which returns INT_RESULT and doesn't have unsigned flag. As it's not a descendant of the Field_num, so using ((Field_num *) field_bit)->unsigned_flag may lead to unpredictable results. Fix: check the field type before casting. mysql-test/r/type_bit.result: Fix for bug #42803: Field_bit does not have unsigned_flag field, can lead to bad memory access - test result. mysql-test/t/type_bit.test: Fix for bug #42803: Field_bit does not have unsigned_flag field, can lead to bad memory access - test case. sql/opt_range.cc: Fix for bug #42803: Field_bit does not have unsigned_flag field, can lead to bad memory access - don't cast to (Field_num *) Field_bit, as it's not a Field_num descendant and is always unsigned by nature.
-
- 30 Aug, 2009 1 commit
-
-
Alexey Kopytov authored
results in server crash check_group_min_max_predicates() assumed the input condition item to be one of COND_ITEM, SUBSELECT_ITEM, or FUNC_ITEM. Since a condition of the form "field" is also a valid condition equivalent to "field <> 0", using such a condition in a query where the loose index scan was chosen resulted in a debug assertion failure. Fixed by handling conditions of the FIELD_ITEM type in check_group_min_max_predicates(). mysql-test/r/group_min_max.result: Added a test case for bug #46607. mysql-test/t/group_min_max.test: Added a test case for bug #46607. sql/opt_range.cc: Handle conditions of the FUNC_ITEM type in check_group_mix_max_predicates().
-
- 28 Aug, 2009 1 commit
-
-
Staale Smedseng authored
with gcc 4.3.2 This patch fixes a number of GCC warnings about variables used before initialized. A new macro UNINIT_VAR() is introduced for use in the variable declaration, and LINT_INIT() usage will be gradually deprecated. (A workaround is used for g++, pending a patch for a g++ bug.) GCC warnings for unused results (attribute warn_unused_result) for a number of system calls (present at least in later Ubuntus, where the usual void cast trick doesn't work) are also fixed. client/mysqlmanager-pwgen.c: A fix for warn_unused_result, adding fallback to use of srand()/rand() if /dev/random cannot be used. Also actually adds calls to rand() in the second branch so that it actually creates a random password.
-
- 26 Aug, 2009 2 commits
-
-
Mattias Jonsson authored
Problem was that the partition containing NULL values was pruned away, since '2001-01-01' < '2001-02-00' but TO_DAYS('2001-02-00') is NULL. Added the NULL partition for RANGE/LIST partitioning on TO_DAYS() function to be scanned too. Also fixed a bug that added ALLOW_INVALID_DATES to sql_mode (SELECT * FROM t WHERE date_col < '1999-99-99' on a RANGE/LIST partitioned table would add it). mysql-test/include/partition_date_range.inc: Bug#20577: Partitions: use of to_days() function leads to selection failures Added include file to decrease test code duplication mysql-test/r/partition_pruning.result: Bug#20577: Partitions: use of to_days() function leads to selection failures Added test results mysql-test/r/partition_range.result: Bug#20577: Partitions: use of to_days() function leads to selection failures Updated test result. This fix adds the partition containing NULL values to the list of partitions to be scanned. mysql-test/t/partition_pruning.test: Bug#20577: Partitions: use of to_days() function leads to selection failures Added test case sql/item.h: Bug#20577: Partitions: use of to_days() function leads to selection failures Added MONOTONIC_*INCREASE_NOT_NULL values to be used by TO_DAYS. sql/item_timefunc.cc: Bug#20577: Partitions: use of to_days() function leads to selection failures Calculate the number of days as return value even for invalid dates. This is so that pruning can be used even for invalid dates. sql/opt_range.cc: Bug#20577: Partitions: use of to_days() function leads to selection failures Fixed a bug that added ALLOW_INVALID_DATES to sql_mode (SELECT * FROM t WHERE date_col < '1999-99-99' on a RANGE/LIST partitioned table would add it). sql/partition_info.h: Bug#20577: Partitions: use of to_days() function leads to selection failures Resetting ret_null_part when a single partition is to be used, this to avoid adding the NULL partition. sql/sql_partition.cc: Bug#20577: Partitions: use of to_days() function leads to selection failures Always include the NULL partition if RANGE or LIST. Use the returned value for the function for pruning, even if it is marked as NULL, so that even '2000-00-00' can be used for pruning, even if TO_DAYS('2000-00-00') is NULL. Changed == to >= in get_next_partition_id_list to avoid crash if part_iter->part_nums is not correctly setup.
-
Mattias Jonsson authored
There were a problem since pruning uses the field for comparison (while evaluate_join_record uses longlong), resulting in pruning failures when comparing DATE to DATETIME. Fix was to always comparing DATE vs DATETIME as DATETIME, by adding ' 00:00:00' to the DATE string. And adding optimization for comparing with 23:59:59, so that DATETIME_col > '2001-02-03 23:59:59' -> TO_DAYS(DATETIME_col) > TO_DAYS('2001-02-03 23:59:59') instead of '>='. mysql-test/r/partition_pruning.result: Bug#46362: Endpoint should be set to false for TO_DAYS(DATE) Updated result-file mysql-test/t/partition_pruning.test: Bug#46362: Endpoint should be set to false for TO_DAYS(DATE) Added testcases. sql-common/my_time.c: Bug#46362: Endpoint should be set to false for TO_DAYS(DATE) removed duplicate assignment. sql/item.cc: Bug#46362: Endpoint should be set to false for TO_DAYS(DATE) Changed field_is_equal_to_item into field_cmp_to_item, to better handling DATE vs DATETIME comparision. sql/item.h: Bug#46362: Endpoint should be set to false for TO_DAYS(DATE) Updated comment sql/item_timefunc.cc: Bug#46362: Endpoint should be set to false for TO_DAYS(DATE) Added optimization (pruning) of DATETIME where time-part is 23:59:59 sql/opt_range.cc: Bug#46362: Endpoint should be set to false for TO_DAYS(DATE) Using the new stored_field_cmp_to_item for better pruning.
-
- 24 Aug, 2009 1 commit
-
-
Georgi Kodinov authored
The code was using a special global buffer for the value of IS NULL ranges. This was not always long enough to be copied by a regular memcpy. As a result read buffer overflows may occur. Fixed by setting the null byte to 1 and setting the rest of the field disk image to NULL with a bzero (instead of relying on the buffer and memcpy()).
-
- 19 Aug, 2009 1 commit
-
-
Georgi Kodinov authored
The check for stack overflow was independent of the size of the structure stored in the heap. Fixed by adding sizeof(PARAM) to the requested free heap size.
-
- 16 Jul, 2009 1 commit
-
-
Georgi Kodinov authored
Fixed various compilation warnings when compiling on a 64 bit windows.
-
- 09 Jul, 2009 1 commit
-
-
Georgi Kodinov authored
When the function exits with an error it was not freeing the local Unique class instance. Fixed my making sure all the places where the function returns from are freeing the Unique instance
-
- 12 Jun, 2009 1 commit
-
-
Georgi Kodinov authored
WHERE and GROUP BY clause Loose index scan may use range conditions on the argument of the MIN/MAX aggregate functions to find the beginning/end of the interval that satisfies the range conditions in a single go. These range conditions may have open or closed minimum/maximum values. When the comparison returns 0 (equal) the code should check the type of the min/max values of the current interval and accept or reject the row based on whether the limit is open or not. There was a wrong composite condition on checking this and it was not working in all cases. Fixed by simplifying the conditions and reversing the logic. mysql-test/r/group_min_max.result: Bug #45386: test case mysql-test/t/group_min_max.test: Bug #45386: test case sql/opt_range.cc: Bug #45386: fix the check whether to use the value if on the interval boundry
-
- 10 Jun, 2009 1 commit
-
-
Martin Hansson authored
Range analysis did not request sorted output from the storage engine, which cause partitioned handlers to process one partition at a time while reading key prefixes in ascending order, causing values to be missed. Fixed by always requesting sorted order during range analysis. This fix is introduced in 6.0 by the fix for bug no 41136. mysql-test/r/group_min_max.result: Bug#44821: Test result. mysql-test/t/group_min_max.test: Bug#44821: Test case sql/opt_range.cc: Bug#44821: Fix.
-
- 09 Jun, 2009 2 commits
-
-
Staale Smedseng authored
with gcc 4.3.2 Compiling MySQL with gcc 4.3.2 and later produces a number of warnings, many of which are new with the recent compiler versions. This bug will be resolved in more than one patch to limit the size of changesets. This is the first patch, fixing a number of the warnings, predominantly "suggest using parentheses around && in ||", and empty for and while bodies.
-
Staale Smedseng authored
with gcc 4.3.2 Compiling MySQL with gcc 4.3.2 and later produces a number of warnings, many of which are new with the recent compiler versions. This bug will be resolved in more than one patch to limit the size of changesets. This is the first patch, fixing a number of the warnings, predominantly "suggest using parentheses around && in ||", and empty for and while bodies.
-
- 30 Apr, 2009 1 commit
-
-
Daniel Fischer authored
-
- 11 Mar, 2009 1 commit
-
-
Sergey Petrunia authored
mysql-test/r/index_merge_myisam.result: Testcases mysql-test/t/index_merge_myisam.test: Testcases sql/strfunc.cc: Change optimizer_switch from no_xxx to xxx=on/xx=off. - Add functions to parse the new syntax
-
- 27 Feb, 2009 1 commit
-
-
Georgi Kodinov authored
return no rows The algorithm of determining the best key for loose index scan is doing a loop over the available indexes and selects the one that has the best cost. It retrieves the parameters of the current index into a set of variables. If the cost of using the current index is lower than the best cost so far it copies these variables into another set of variables that contain the information for the best index so far. After having checked all the indexes it uses these variables (outside of the index loop) to create the table read plan object instance. The was a single omission : the key_infix/key_infix_len variables were used outside of the loop without being preserved in the loop for the best index so far. This causes these variables to get overwritten by the next index(es) checked. Fixed by adding variables to hold the data for the current index, passing the new variables to the function that assigns values to them and copying the new variables into the existing ones when selecting a new current best index. To avoid further such problems moved the declarations of the variables used to keep information about the current index inside the loop's compound statement. mysql-test/r/group_min_max.result: Bug #41610: test case mysql-test/t/group_min_max.test: Bug #41610: test case sql/opt_range.cc: Bug #41610: copy the infix data for the current best index
-
- 23 Feb, 2009 1 commit
-
-
Sergey Petrunia authored
- Add support for setting it as a server commandline argument - Add support for those switches: = no_index_merge = no_index_merge_union = no_index_merge_sort_union = no_index_merge_intersection mysql-test/r/index_merge_myisam.result: Testcases for index_merge related @@optimizer_switch flags. mysql-test/t/index_merge_myisam.test: Testcases for index_merge related @@optimizer_switch flags. sql/set_var.cc: - Backport @@optimizer_switch support from 6.0 - Add support for setting it as a server commandline argument sql/sql_class.h: - Backport @@optimizer_switch support from 6.0 sql/sql_select.h: - Backport @@optimizer_switch support from 6.0
-
- 10 Feb, 2009 1 commit
-
-
Ignacio Galarza authored
- Remove bothersome warning messages. This change focuses on the warnings that are covered by the ignore file: support-files/compiler_warnings.supp. - Strings are guaranteed to be max uint in length
-
- 19 Dec, 2008 1 commit
-
-
Sergey Petrunia authored
- QUICK_INDEX_MERGE_SELECT deinitializes its rnd_pos() scan when it reaches EOF, but we need to make the deinitialization in QUICK_INDEX_MERGE_SELECT destructor also. This is because certain execution strategies can stop scanning without reaching EOF, then then try to do a full table scan on this table. Failure to deinitialize caused the full scan to use (already empty) table->sort and produce zero records. mysql-test/r/index_merge.result: BUG#40974: Incorrect query results when using clause evaluated using range check - Testcase mysql-test/t/index_merge.test: BUG#40974: Incorrect query results when using clause evaluated using range check - Testcase
-
- 09 Dec, 2008 1 commit
-
-
Georgi Kodinov authored
-