BUG#13519696 - 62940: SELECT RESULTS VARY WITH VERSION AND
WITH/WITHOUT INDEX RANGE SCAN
BUG#13453382 - REGRESSION SINCE 5.1.39, RANGE OPTIMIZER WRONG
RESULTS WITH DECIMAL CONVERSION
BUG#13463488 - 63437: CHAR & BETWEEN WITH INDEX RETURNS WRONG
RESULT AFTER MYSQL 5.1.
Those are all cases where the range optimizer got it wrong
with > and >=.
mysql-test/r/range.result:
Without the code fix for DECIMAL, "select count(val) from t2 where val > 0.1155"
(which uses a range scan) returned 127 instead of 128);
Moreover, both
select * from t1 force index (primary) where a=1 and c>= 2.9;
and
select * from t1 force index (primary) where a=1 and c> 2.9;
would miss "1 1 3".
Without the code fix for strings, both
SELECT * FROM t1 WHERE F1 >= 'A ';
and
SELECT * FROM t1 WHERE F1 BETWEEN 'A ' AND 'AAAAA';
would miss "A A A".
sql/item.cc:
Preamble to the explanations below: opt_range.cc:get_mm_leaf() does
this (this is not changed by the patch): changes
column > value
to
column OP V
where:
* V is what is in "column" after we stored "value" in it
(such store operation may have done rounding...)
* OP is > or >=, depending on what's correct.
For example, if c is an INT column,
c > 2.9 is changed to
c OP 3
where OP is >= ('>' would not be correct).
The bugs below are cases where we chose OP wrongly.
Note that such transformations are visible in the optimizer trace.
1) Fix for STRING. In the scenario with CHAR(5) in range.test, this happens,
in get_mm_tree(), for the condition F1>='A ':
* value->save_in_field_no_warnings(field, 1) wants to store the right argument
(named 'item') into the CHAR(5) field; this stores 'A ' (the item's value)
padded with spaces (which changes nothing: still 'A ')
* we come to
case Item_func::GE_FUNC:
/* Don't use open ranges for partial key_segments */
if ((!(key_part->flag & HA_PART_KEY_SEG)) &&
(stored_field_cmp_to_item(param->thd, field, value) < 0))
tree->min_flag= NEAR_MIN;
tree->max_flag=NO_MAX_RANGE;
What this wants to do is: if the field's value is strictly smaller
than the item's, then ">=" can be changed to ">" (this is an optimization,
it can help pruning one useless partition).
* stored_field_cmp_to_item() is called; it compares the field's
and item's values: the item's value (Item_string::val_str()) is
'A ') and the field's value (Field_string::val_str()) is
'A' (yes val_str() removes end spaces unless sql_mode='PAD_CHAR_TO_FULL_LENGTH');
and the comparison is done with stringcmp() which considers
end spaces as relevant; as end spaces differ, function returns a
negative number, and ">='A '" becomes ">'A'" (i.e. the NEAR_MIN
flag is turned on).
During execution the index range scan code will search for "A", find
a match, but exclude it (because of ">"), wrongly.
The badness is the string comparison done by stored_field_cmp_to_item():
we use the reply of this function to determine where the index search
should start, so it should do comparison like index search does
comparisons; index search comparisons are ha_key_cmp() which uses
a collation-aware comparison (in our case, my_strnncollsp_simple(),
which ignores end spaces); so stored_field_cmp_to_item()
needs to do the same. When this is fixed, condition becomes
">='A '".
2) Fix for DECIMAL: just like in other comparisons in stored_field_cmp_to_item(),
we must first pass the field and then the item; otherwise expectations
on what <0 and >0 mean (inferiority, superiority) get violated.
In the test in range.test about c>2.9: c is an INT column, so 2.9
gets stored as 3, then stored_field_cmp_to_item() compares 3
and 2.9; because of the wrong order of arguments passed
to my_decimal_cmp(), range optimizer
thinks that 3 is < 2.9 and thus changes "c> 2.9" to "c> 3".
After fixing the order, it changes to the correct "c>= 3".
In the test in range.inc for val > 0.1155, it was changed to
val > 0.116, now it is changed to val >= 0.116.
Root cause for this bug is that the optimizer try to detect&
optimize the special case:
'<field> BETWEEN c1 AND c1' and handle this as the condition '<field> = c1'
This was implemented inside add_key_field(.. *field, *value[]...)
which assumed field to refer key Field, and value[] to refer a [low...high]
constant pair. value[0] and value[1] was then compared for equality.
In a 'normal' BETWEEN condition of the form '<field> BETWEEN val1 and val2' the
BETWEEN operation is represented with an argementlist containing the
values [<field>, val1, val2] - add_key_field() is then called with
parameters field=<field>, *value=val1.
However, if the BETWEEN predicate specified:
1) '<const1> BETWEEN<const2> AND<field>
the 'field' and 'value' arguments to add_key_field() had to be swapped.
This was implemented by trying to cheat add_key_field() to handle it like:
2) '<const1> GE<const2> AND<const1> LE<field>'
As we didn't really replace the BETWEEN operation with 'ge' and 'le',
add_key_field() still handled it as a 'BETWEEN' and compared the (swapped)
arguments<const1> and<const2> for equality. If they was equal, the
condition 1) was incorrectly 'optimized' to:
3) '<field> EQ <const1>'
This fix moves this optimization of '<field> BETWEEN c1 AND c1' into
add_key_fields() which then calls add_key_equal_fields() to collect
key equality / comparison for the key fields in the BETWEEN condition.
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.
feature
The test for bug no 50939 was put in range.test which isn't such a good idea
since it requires partitioning. Fixed by moving the test case to
partitioning_range.test.
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.
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.
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().
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
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.
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.
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.
WHERE f1 < n ignored row if f1 was indexed integer column and
f1 = TYPE_MAX ^ n = TYPE_MAX+1. The latter value when treated
as TYPE overflowed (obviously). This was not handled, it is now.
mysql-test/r/range.result:
show that on an index int column, we no longer disregard
a field val of TYPE_MAX in SELECT ... WHERE ... < TYPE_MAX+1
mysql-test/t/range.test:
show that on an index int column, we no longer disregard
a field val of TYPE_MAX in SELECT ... WHERE ... < TYPE_MAX+1
sql/opt_range.cc:
Handle overflowing of int-types in range-optimizer.
Unfortunately requires re-indentation of entire block.
Overflow (err == 1) was handled, but only if
field->cmp_type() != value->result_type(), which it
just wasn't in our case.
into kaamos.(none):/data/src/opt/mysql-5.1-opt
mysql-test/r/heap.result:
Auto merged
mysql-test/r/innodb.result:
Auto merged
mysql-test/r/myisam.result:
Auto merged
BitKeeper/deleted/.del-bdb.result:
Auto merged
mysql-test/r/strict.result:
Auto merged
mysql-test/r/type_binary.result:
Auto merged
mysql-test/r/type_set.result:
Auto merged
mysql-test/r/variables.result:
Auto merged
mysql-test/r/warnings.result:
Auto merged
mysql-test/t/range.test:
Auto merged
mysql-test/t/variables.test:
Auto merged
mysql-test/t/warnings.test:
Auto merged
sql/field.cc:
Auto merged
sql/field.h:
Auto merged
sql/item.cc:
Auto merged
sql/item.h:
Auto merged
sql/item_func.cc:
Auto merged
sql/sql_select.cc:
Auto merged
sql/mysqld.cc:
Null merge.
mysql-test/include/mix1.inc:
Manual merge.
mysql-test/r/innodb_mysql.result:
Manual merge.
mysql-test/r/range.result:
Manual merge.
mysql-test/r/sp.result:
Manual merge.
mysql-test/t/sp.test:
Manual merge.
sql/handler.cc:
Manual merge.
Two disjuncts containing equalities of the form key=const1 and key=const2 can
be merged into one if const1 is equal to const2. To check it the common
collation of the constants were used rather than the collation of the field key.
For example when the default collation of the constants was cases insensitive
while the collation of the field was case sensitive, then two or-ed equality
predicates key='b' and key='B' incorrectly were merged into one f='b'. As a
result ref access was used instead of range access and wrong result sets were
returned in many cases.
Fixed the problem by comparing constant in the or-ed predicate with collation of
the key field.
mysql-test/r/range.result:
Added a test case for bug #33833.
mysql-test/t/range.test:
Added a test case for bug #33833.
sql/item.cc:
Fixed bug #33833.
Added the method eq_by_collation that compares two items almost as
the method Item::eq, but it rather enforces a given collation for
the comparison.
sql/item.h:
Fixed bug #33833.
Added the method eq_by_collation that compares two items almost as
the method Item::eq, but it rather enforces a given collation for
the comparison.
into mysql.com:/home/gluh/MySQL/Merge/5.1-opt
client/mysql.cc:
Auto merged
client/mysqltest.c:
Auto merged
include/mysql_com.h:
Auto merged
libmysql/CMakeLists.txt:
Auto merged
mysql-test/r/delayed.result:
Auto merged
mysql-test/r/func_misc.result:
Auto merged
mysql-test/r/innodb.result:
Auto merged
mysql-test/r/myisam.result:
Auto merged
mysql-test/r/ps.result:
Auto merged
mysql-test/t/func_misc.test:
Auto merged
mysql-test/t/merge.test:
Auto merged
mysql-test/t/myisam.test:
Auto merged
mysql-test/t/range.test:
Auto merged
mysql-test/t/subselect.test:
Auto merged
mysql-test/t/type_datetime.test:
Auto merged
mysql-test/t/variables.test:
Auto merged
sql/field.cc:
Auto merged
sql/item.cc:
Auto merged
sql/item.h:
Auto merged
sql/item_func.cc:
Auto merged
sql/item_func.h:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/mysqld.cc:
Auto merged
sql/opt_range.cc:
Auto merged
sql/set_var.cc:
Auto merged
sql/set_var.h:
Auto merged
sql/sql_class.h:
Auto merged
sql/sql_insert.cc:
Auto merged
sql/sql_select.cc:
Auto merged
sql/sql_table.cc:
Auto merged
sql/sql_yacc.yy:
Auto merged
storage/myisam/ha_myisam.cc:
Auto merged
storage/myisam/mi_check.c:
Auto merged
mysql-test/include/mix1.inc:
manual merge
mysql-test/r/innodb_mysql.result:
manual merge
mysql-test/r/range.result:
manual merge
sql/item_cmpfunc.cc:
manual merge
- Make conditions like "date_col $CMP$ 'datetime-const'" range-sargable
mysql-test/r/range.result:
BUG#32198: Comparison of DATE with DATETIME still not using indexes correctly
- Testcase
mysql-test/t/range.test:
BUG#32198: Comparison of DATE with DATETIME still not using indexes correctly
- Testcase
sql/field.cc:
BUG#32198: Comparison of DATE with DATETIME still not using indexes correctly
- Added comments
- Renamed "Using join cache" to "Using join buffer".
- "Using join buffer" is now printed on the last
table that "reads" from the join buffer cache.
mysql-test/r/archive_gis.result:
Bug #27531: renamed "Using join cache" to "Using join buffer"
and moved to the last table in the batch.
mysql-test/r/compress.result:
Bug #27531: renamed "Using join cache" to "Using join buffer"
and moved to the last table in the batch.
mysql-test/r/ctype_utf8.result:
Bug #27531: renamed "Using join cache" to "Using join buffer"
and moved to the last table in the batch.
mysql-test/r/derived.result:
Bug #27531: renamed "Using join cache" to "Using join buffer"
and moved to the last table in the batch.
mysql-test/r/distinct.result:
Bug #27531: renamed "Using join cache" to "Using join buffer"
and moved to the last table in the batch.
mysql-test/r/func_group.result:
Bug #27531: renamed "Using join cache" to "Using join buffer"
and moved to the last table in the batch.
mysql-test/r/func_group_innodb.result:
Bug #27531: renamed "Using join cache" to "Using join buffer"
and moved to the last table in the batch.
mysql-test/r/gis.result:
Bug #27531: renamed "Using join cache" to "Using join buffer"
and moved to the last table in the batch.
mysql-test/r/greedy_optimizer.result:
Bug #27531: renamed "Using join cache" to "Using join buffer"
and moved to the last table in the batch.
mysql-test/r/group_by.result:
Bug #27531: renamed "Using join cache" to "Using join buffer"
and moved to the last table in the batch.
mysql-test/r/group_min_max.result:
Bug #27531: renamed "Using join cache" to "Using join buffer"
and moved to the last table in the batch.
mysql-test/r/index_merge_myisam.result:
Bug #27531: renamed "Using join cache" to "Using join buffer"
and moved to the last table in the batch.
mysql-test/r/information_schema.result:
Bug #27531: renamed "Using join cache" to "Using join buffer"
and moved to the last table in the batch.
mysql-test/r/innodb_gis.result:
Bug #27531: renamed "Using join cache" to "Using join buffer"
and moved to the last table in the batch.
mysql-test/r/innodb_mysql.result:
Bug #27531: renamed "Using join cache" to "Using join buffer"
and moved to the last table in the batch.
mysql-test/r/join.result:
Bug #27531: renamed "Using join cache" to "Using join buffer"
and moved to the last table in the batch.
mysql-test/r/join_nested.result:
Bug #27531: renamed "Using join cache" to "Using join buffer"
and moved to the last table in the batch.
mysql-test/r/key_diff.result:
Bug #27531: renamed "Using join cache" to "Using join buffer"
and moved to the last table in the batch.
mysql-test/r/myisam.result:
Bug #27531: renamed "Using join cache" to "Using join buffer"
and moved to the last table in the batch.
mysql-test/r/ndb_condition_pushdown.result:
Bug #27531: renamed "Using join cache" to "Using join buffer"
and moved to the last table in the batch.
mysql-test/r/ndb_gis.result:
Bug #27531: renamed "Using join cache" to "Using join buffer"
and moved to the last table in the batch.
mysql-test/r/range.result:
Bug #27531: renamed "Using join cache" to "Using join buffer"
and moved to the last table in the batch.
mysql-test/r/row.result:
Bug #27531: renamed "Using join cache" to "Using join buffer"
and moved to the last table in the batch.
mysql-test/r/select.result:
Bug #27531: renamed "Using join cache" to "Using join buffer"
and moved to the last table in the batch.
mysql-test/r/ssl.result:
Bug #27531: renamed "Using join cache" to "Using join buffer"
and moved to the last table in the batch.
mysql-test/r/ssl_compress.result:
Bug #27531: renamed "Using join cache" to "Using join buffer"
and moved to the last table in the batch.
mysql-test/r/subselect.result:
Bug #27531: renamed "Using join cache" to "Using join buffer"
and moved to the last table in the batch.
mysql-test/r/subselect3.result:
Bug #27531: renamed "Using join cache" to "Using join buffer"
and moved to the last table in the batch.
mysql-test/r/union.result:
Bug #27531: renamed "Using join cache" to "Using join buffer"
and moved to the last table in the batch.
mysql-test/r/view.result:
Bug #27531: renamed "Using join cache" to "Using join buffer"
and moved to the last table in the batch.
sql/sql_select.cc:
Bug #27531: renamed "Using join cache" to "Using join buffer"
and moved to the last table in the batch.
- added join cache indication in EXPLAIN (Extra column).
- prefer filesort over full scan over
index for ORDER BY (because it's faster).
- when switching from REF to RANGE because
RANGE uses longer key turn off sort on
the head table only as the resulting
RANGE access is a candidate for join cache
and we don't want to disable it by sorting
on the first table only.
mysql-test/r/archive_gis.result:
bug #27531: join cache in EXPLAIN
mysql-test/r/compress.result:
bug #27531:
- join cache in EXPLAIN.
- prefer filesort over full scan over index for ORDER BY.
mysql-test/r/ctype_utf8.result:
bug #27531: join cache in EXPLAIN
mysql-test/r/derived.result:
bug #27531: join cache in EXPLAIN
mysql-test/r/distinct.result:
bug #27531: join cache in EXPLAIN
mysql-test/r/func_group.result:
bug #27531: join cache in EXPLAIN
mysql-test/r/func_group_innodb.result:
bug #27531: join cache in EXPLAIN
mysql-test/r/gis.result:
bug #27531: join cache in EXPLAIN
mysql-test/r/greedy_optimizer.result:
bug #27531: join cache in EXPLAIN
mysql-test/r/group_by.result:
bug #27531: join cache in EXPLAIN
mysql-test/r/group_min_max.result:
bug #27531: join cache in EXPLAIN
mysql-test/r/index_merge_myisam.result:
bug #27531: join cache in EXPLAIN
mysql-test/r/information_schema.result:
bug #27531: join cache in EXPLAIN
mysql-test/r/innodb_gis.result:
bug #27531: join cache in EXPLAIN
mysql-test/r/innodb_mysql.result:
bug #27531: join cache in EXPLAIN
mysql-test/r/join.result:
bug #27531: join cache in EXPLAIN
mysql-test/r/join_nested.result:
bug #27531: join cache in EXPLAIN
mysql-test/r/key_diff.result:
bug #27531: join cache in EXPLAIN
mysql-test/r/myisam.result:
bug #27531: join cache in EXPLAIN
mysql-test/r/ndb_condition_pushdown.result:
bug #27531: join cache in EXPLAIN
mysql-test/r/ndb_gis.result:
bug #27531: join cache in EXPLAIN
mysql-test/r/range.result:
bug #27531: join cache in EXPLAIN
mysql-test/r/row.result:
bug #27531: join cache in EXPLAIN
mysql-test/r/select.result:
bug #27531:
- join cache in EXPLAIN.
- prefer filesort over full scan over index for ORDER BY.
mysql-test/r/ssl.result:
bug #27531:
- join cache in EXPLAIN.
- prefer filesort over full scan over index for ORDER BY.
mysql-test/r/ssl_compress.result:
bug #27531:
- join cache in EXPLAIN.
- prefer filesort over full scan over index for ORDER BY.
mysql-test/r/subselect.result:
bug #27531: join cache in EXPLAIN
mysql-test/r/subselect3.result:
bug #27531: join cache in EXPLAIN
mysql-test/r/union.result:
bug #27531: join cache in EXPLAIN
mysql-test/r/view.result:
bug #27531: join cache in EXPLAIN
sql/sql_select.cc:
bug #27531:
- join cache in EXPLAIN.
- prefer filesort over full scan over
index for ORDER BY.
- disable sorting on the first table only
when switching from REF to RANGE.
into mysql.com:/home/psergey/mysql-5.1-merge2
mysql-test/r/range.result:
Auto merged
mysql-test/t/range.test:
Auto merged
sql/opt_range.cc:
Auto merged
Pushbuild fixes:
- Make MAX_SEL_ARGS smaller (even 16K records_in_range() calls is
more than it makes sense to do in typical cases)
- Don't call sel_arg->test_use_count() if we've already allocated
more than MAX_SEL_ARGs elements. The test will succeed but will take
too much time for the test suite (and not provide much value).
mysql-test/r/range.result:
BUG#26624: high mem usage (crash) in range optimizer
Pushbuild fixes: make the test go faster
mysql-test/t/range.test:
BUG#26624: high mem usage (crash) in range optimizer
Pushbuild fixes: make the test go faster
into mysql.com:/home/psergey/mysql-5.1-merge
BitKeeper/deleted/.del-mysqld.cc.rej:
Auto merged
mysql-test/r/range.result:
Auto merged
mysql-test/t/range.test:
Auto merged
sql/item_sum.cc:
Auto merged
sql/sql_list.h:
Auto merged
mysql-test/r/subselect.result:
Manual merge
mysql-test/t/subselect.test:
Manual merge
sql/opt_range.cc:
Manual merge
- Added PARAM::alloced_sel_args where we count the # of SEL_ARGs
created by SEL_ARG tree cloning operations.
- Made the range analyzer to shortcut and not do any more cloning
if we've already created MAX_SEL_ARGS SEL_ARG objects in cloning.
- Added comments about space complexity of SEL_ARG-graph
representation.
mysql-test/r/range.result:
BUG#26624: Testcase
mysql-test/t/range.test:
BUG#26624: Testcase
into zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-4.1-maint
configure.in:
Auto merged
mysql-test/r/range.result:
Auto merged
mysql-test/t/range.test:
Auto merged
into mysql.com:/home/gluh/MySQL/Merge/5.1-opt
BitKeeper/etc/ignore:
auto-union
mysql-test/r/func_in.result:
Auto merged
mysql-test/r/range.result:
Auto merged
mysql-test/r/sp-code.result:
Auto merged
mysql-test/r/trigger.result:
Auto merged
mysql-test/r/udf.result:
Auto merged
mysql-test/t/func_in.test:
Auto merged
mysql-test/t/range.test:
Auto merged
mysql-test/t/trigger.test:
Auto merged
sql/item.cc:
Auto merged
sql/item.h:
Auto merged
sql/item_func.cc:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/sql_base.cc:
Auto merged
sql/sql_insert.cc:
Auto merged
sql/sql_lex.cc:
Auto merged
sql/sql_lex.h:
Auto merged
sql/sql_prepare.cc:
Auto merged
sql/sql_select.cc:
Auto merged
sql/sql_show.cc:
Auto merged
sql/sql_table.cc:
Auto merged
mysql-test/r/select.result:
manual merge
mysql-test/r/view.result:
manual merge
mysql-test/t/select.test:
manual merge
mysql-test/t/view.test:
manual merge
into macbook.gmz:/Users/kgeorge/mysql/work/merge-5.1-opt
mysql-test/r/func_in.result:
Auto merged
mysql-test/r/range.result:
Auto merged
mysql-test/r/select.result:
Auto merged
mysql-test/r/sp-code.result:
Auto merged
mysql-test/r/trigger.result:
Auto merged
mysql-test/r/udf.result:
Auto merged
mysql-test/r/view.result:
Auto merged
mysql-test/t/func_in.test:
Auto merged
mysql-test/t/func_str.test:
Auto merged
mysql-test/t/range.test:
Auto merged
mysql-test/t/select.test:
Auto merged
mysql-test/t/trigger.test:
Auto merged
mysql-test/t/udf.test:
Auto merged
sql/item.cc:
Auto merged
sql/item.h:
Auto merged
sql/item_cmpfunc.cc:
Auto merged
sql/item_func.cc:
Auto merged
sql/item_strfunc.cc:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/opt_range.h:
Auto merged
sql/sql_base.cc:
Auto merged
sql/sql_delete.cc:
Auto merged
sql/sql_insert.cc:
Auto merged
sql/sql_lex.cc:
Auto merged
sql/sql_lex.h:
Auto merged
sql/sql_prepare.cc:
Auto merged
sql/sql_select.cc:
Auto merged
sql/sql_table.cc:
Auto merged
sql/sql_union.cc:
Auto merged
sql/sql_update.cc:
Auto merged
mysql-test/r/func_str.result:
merge 5.0-opt -> 5.1-opt
mysql-test/r/group_by.result:
merge 5.0-opt -> 5.1-opt
mysql-test/r/insert.result:
merge 5.0-opt -> 5.1-opt
mysql-test/r/subselect.result:
merge 5.0-opt -> 5.1-opt
mysql-test/t/group_by.test:
merge 5.0-opt -> 5.1-opt
mysql-test/t/insert.test:
merge 5.0-opt -> 5.1-opt
mysql-test/t/subselect.test:
merge 5.0-opt -> 5.1-opt
mysql-test/t/view.test:
merge 5.0-opt -> 5.1-opt
sql/item_cmpfunc.h:
merge 5.0-opt -> 5.1-opt
sql/item_strfunc.h:
merge 5.0-opt -> 5.1-opt
into mysql.com:/home/gluh/MySQL/Merge/5.0-opt
mysql-test/r/func_in.result:
Auto merged
mysql-test/r/range.result:
Auto merged
mysql-test/r/sp-code.result:
Auto merged
mysql-test/t/func_in.test:
Auto merged
mysql-test/t/range.test:
Auto merged
mysql-test/t/trigger.test:
Auto merged
mysql-test/t/view.test:
Auto merged
sql/item.cc:
Auto merged
sql/item_func.cc:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/sql_insert.cc:
Auto merged
sql/sql_lex.cc:
Auto merged
sql/sql_lex.h:
Auto merged
sql/sql_prepare.cc:
Auto merged
sql/sql_select.cc:
Auto merged
sql/sql_table.cc:
Auto merged
mysql-test/r/select.result:
manual merge
mysql-test/r/view.result:
manual merge
mysql-test/t/select.test:
manual merge
into mysql.com:/usr/home/ram/work/bug22533/my51-bug22533
mysql-test/r/range.result:
Auto merged
mysql-test/r/type_bit.result:
Auto merged
mysql-test/r/type_bit_innodb.result:
Auto merged
sql/field.cc:
Auto merged
into olga.mysql.com:/home/igor/mysql-5.0-opt
mysql-test/r/range.result:
Auto merged
mysql-test/t/range.test:
Auto merged
sql/opt_range.h:
Manual merge.
for queries using 'range checked for each record'.
The problem was fixed in 5.0 by the patch for bug 12291.
This patch down-ported the corresponding code from 5.0 into
QUICK_SELECT::init() and added a new test case.
mysql-test/r/range.result:
Added a test case for bug #24776.
mysql-test/t/range.test:
Added a test case for bug #24776.
sql/opt_range.h:
Fixed bug #24776: an assertion abort in handler::ha_index_init
for queries using 'range checked for each record'.
The problem was fixed in 5.0 by the patch for bug 12291.
The patch for 4.1 down-ported the corresponding code from 5.0 into
QUICK_SELECT::init().
into mysql.com:/usr/home/ram/work/bug20732/my51-bug20732
mysql-test/r/range.result:
Auto merged
mysql-test/t/range.test:
Auto merged
sql/opt_range.cc:
Auto merged
sql/opt_range.h:
Auto merged
sql/sql_select.cc:
Auto merged
sql/table.cc:
manual merging.
into mysql.com:/usr/home/ram/work/bug20732/my50-bug20732
sql/opt_range.cc:
Auto merged
sql/opt_range.h:
Auto merged
sql/sql_select.cc:
Auto merged
sql/table.cc:
Auto merged
mysql-test/r/range.result:
SCCS merged
mysql-test/t/range.test:
SCCS merged
