mariadb/mysql-test/main/negation_elimination.result

507 lines
8.7 KiB
Text
Raw Normal View History

drop table if exists t1;
create table t1 (a int, key (a));
insert into t1 values (NULL), (0), (1), (2), (3), (4), (5), (6), (7), (8), (9),
(10), (11), (12), (13), (14), (15), (16), (17), (18), (19);
explain select * from t1 where not(not(a));
id select_type table type possible_keys key key_len ref rows Extra
Updated optimizer costs in multi_range_read_info_const() and sql_select.cc - multi_range_read_info_const now uses the new records_in_range interface - Added handler::avg_io_cost() - Don't calculate avg_io_cost() in get_sweep_read_cost if avg_io_cost is not 1.0. In this case we trust the avg_io_cost() from the handler. - Changed test_quick_select to use TIME_FOR_COMPARE instead of TIME_FOR_COMPARE_IDX to align this with the rest of the code. - Fixed bug when using test_if_cheaper_ordering where we didn't use keyread if index was changed - Fixed a bug where we didn't use index only read when using order-by-index - Added keyread_time() to HEAP. The default keyread_time() was optimized for blocks and not suitable for HEAP. The effect was the HEAP prefered table scans over ranges for btree indexes. - Fixed get_sweep_read_cost() for HEAP tables - Ensure that range and ref have same cost for simple ranges Added a small cost (MULTI_RANGE_READ_SETUP_COST) to ranges to ensure we favior ref for range for simple queries. - Fixed that matching_candidates_in_table() uses same number of records as the rest of the optimizer - Added avg_io_cost() to JT_EQ_REF cost. This helps calculate the cost for HEAP and temporary tables better. A few tests changed because of this. - heap::read_time() and heap::keyread_time() adjusted to not add +1. This was to ensure that handler::keyread_time() doesn't give higher cost for heap tables than for normal tables. One effect of this is that heap and derived tables stored in heap will prefer key access as this is now regarded as cheap. - Changed cost for index read in sql_select.cc to match multi_range_read_info_const(). All index cost calculation is now done trough one function. - 'ref' will now use quick_cost for keys if it exists. This is done so that for '=' ranges, 'ref' is prefered over 'range'. - scan_time() now takes avg_io_costs() into account - get_delayed_table_estimates() uses block_size and avg_io_cost() - Removed default argument to test_if_order_by_key(); simplifies code
2020-02-28 12:59:30 +02:00
1 SIMPLE t1 range a a 5 NULL 20 Using where; Using index
select * from t1 where not(not(a));
a
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
explain select * from t1 where not(not(not(a > 10)));
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range a a 5 NULL 11 Using where; Using index
select * from t1 where not(not(not(a > 10)));
a
0
1
2
3
4
5
6
7
8
9
10
explain select * from t1 where not(not(not(a < 5) and not(a > 10)));
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range a a 5 NULL 6 Using where; Using index
select * from t1 where not(not(not(a < 5) and not(a > 10)));
a
5
6
7
8
9
10
explain select * from t1 where not(a = 10);
id select_type table type possible_keys key key_len ref rows Extra
Updated optimizer costs in multi_range_read_info_const() and sql_select.cc - multi_range_read_info_const now uses the new records_in_range interface - Added handler::avg_io_cost() - Don't calculate avg_io_cost() in get_sweep_read_cost if avg_io_cost is not 1.0. In this case we trust the avg_io_cost() from the handler. - Changed test_quick_select to use TIME_FOR_COMPARE instead of TIME_FOR_COMPARE_IDX to align this with the rest of the code. - Fixed bug when using test_if_cheaper_ordering where we didn't use keyread if index was changed - Fixed a bug where we didn't use index only read when using order-by-index - Added keyread_time() to HEAP. The default keyread_time() was optimized for blocks and not suitable for HEAP. The effect was the HEAP prefered table scans over ranges for btree indexes. - Fixed get_sweep_read_cost() for HEAP tables - Ensure that range and ref have same cost for simple ranges Added a small cost (MULTI_RANGE_READ_SETUP_COST) to ranges to ensure we favior ref for range for simple queries. - Fixed that matching_candidates_in_table() uses same number of records as the rest of the optimizer - Added avg_io_cost() to JT_EQ_REF cost. This helps calculate the cost for HEAP and temporary tables better. A few tests changed because of this. - heap::read_time() and heap::keyread_time() adjusted to not add +1. This was to ensure that handler::keyread_time() doesn't give higher cost for heap tables than for normal tables. One effect of this is that heap and derived tables stored in heap will prefer key access as this is now regarded as cheap. - Changed cost for index read in sql_select.cc to match multi_range_read_info_const(). All index cost calculation is now done trough one function. - 'ref' will now use quick_cost for keys if it exists. This is done so that for '=' ranges, 'ref' is prefered over 'range'. - scan_time() now takes avg_io_costs() into account - get_delayed_table_estimates() uses block_size and avg_io_cost() - Removed default argument to test_if_order_by_key(); simplifies code
2020-02-28 12:59:30 +02:00
1 SIMPLE t1 range a a 5 NULL 19 Using where; Using index
select * from t1 where not(a = 10);
a
0
1
2
3
4
5
6
7
8
9
11
12
13
14
15
16
17
18
19
explain select * from t1 where not(a != 10);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 ref a a 5 const 1 Using index
select * from t1 where not(a != 1);
a
1
explain select * from t1 where not(a < 10);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range a a 5 NULL 10 Using where; Using index
select * from t1 where not(a < 10);
a
10
11
12
13
14
15
16
17
18
19
explain select * from t1 where not(a >= 10);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range a a 5 NULL 10 Using where; Using index
select * from t1 where not(a >= 10);
a
0
1
2
3
4
5
6
7
8
9
explain select * from t1 where not(a > 10);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range a a 5 NULL 11 Using where; Using index
select * from t1 where not(a > 10);
a
0
1
2
3
4
5
6
7
8
9
10
explain select * from t1 where not(a <= 10);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range a a 5 NULL 9 Using where; Using index
select * from t1 where not(a <= 10);
a
11
12
13
14
15
16
17
18
19
explain select * from t1 where not(a is null);
id select_type table type possible_keys key key_len ref rows Extra
Updated optimizer costs in multi_range_read_info_const() and sql_select.cc - multi_range_read_info_const now uses the new records_in_range interface - Added handler::avg_io_cost() - Don't calculate avg_io_cost() in get_sweep_read_cost if avg_io_cost is not 1.0. In this case we trust the avg_io_cost() from the handler. - Changed test_quick_select to use TIME_FOR_COMPARE instead of TIME_FOR_COMPARE_IDX to align this with the rest of the code. - Fixed bug when using test_if_cheaper_ordering where we didn't use keyread if index was changed - Fixed a bug where we didn't use index only read when using order-by-index - Added keyread_time() to HEAP. The default keyread_time() was optimized for blocks and not suitable for HEAP. The effect was the HEAP prefered table scans over ranges for btree indexes. - Fixed get_sweep_read_cost() for HEAP tables - Ensure that range and ref have same cost for simple ranges Added a small cost (MULTI_RANGE_READ_SETUP_COST) to ranges to ensure we favior ref for range for simple queries. - Fixed that matching_candidates_in_table() uses same number of records as the rest of the optimizer - Added avg_io_cost() to JT_EQ_REF cost. This helps calculate the cost for HEAP and temporary tables better. A few tests changed because of this. - heap::read_time() and heap::keyread_time() adjusted to not add +1. This was to ensure that handler::keyread_time() doesn't give higher cost for heap tables than for normal tables. One effect of this is that heap and derived tables stored in heap will prefer key access as this is now regarded as cheap. - Changed cost for index read in sql_select.cc to match multi_range_read_info_const(). All index cost calculation is now done trough one function. - 'ref' will now use quick_cost for keys if it exists. This is done so that for '=' ranges, 'ref' is prefered over 'range'. - scan_time() now takes avg_io_costs() into account - get_delayed_table_estimates() uses block_size and avg_io_cost() - Removed default argument to test_if_order_by_key(); simplifies code
2020-02-28 12:59:30 +02:00
1 SIMPLE t1 range a a 5 NULL 20 Using where; Using index
select * from t1 where not(a is null);
a
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
explain select * from t1 where not(a is not null);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 ref a a 5 const 1 Using where; Using index
select * from t1 where not(a is not null);
a
NULL
explain select * from t1 where not(a < 5 or a > 15);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range a a 5 NULL 11 Using where; Using index
select * from t1 where not(a < 5 or a > 15);
a
5
6
7
8
9
10
11
12
13
14
15
explain select * from t1 where not(a < 15 and a > 5);
id select_type table type possible_keys key key_len ref rows Extra
Updated optimizer costs in multi_range_read_info_const() and sql_select.cc - multi_range_read_info_const now uses the new records_in_range interface - Added handler::avg_io_cost() - Don't calculate avg_io_cost() in get_sweep_read_cost if avg_io_cost is not 1.0. In this case we trust the avg_io_cost() from the handler. - Changed test_quick_select to use TIME_FOR_COMPARE instead of TIME_FOR_COMPARE_IDX to align this with the rest of the code. - Fixed bug when using test_if_cheaper_ordering where we didn't use keyread if index was changed - Fixed a bug where we didn't use index only read when using order-by-index - Added keyread_time() to HEAP. The default keyread_time() was optimized for blocks and not suitable for HEAP. The effect was the HEAP prefered table scans over ranges for btree indexes. - Fixed get_sweep_read_cost() for HEAP tables - Ensure that range and ref have same cost for simple ranges Added a small cost (MULTI_RANGE_READ_SETUP_COST) to ranges to ensure we favior ref for range for simple queries. - Fixed that matching_candidates_in_table() uses same number of records as the rest of the optimizer - Added avg_io_cost() to JT_EQ_REF cost. This helps calculate the cost for HEAP and temporary tables better. A few tests changed because of this. - heap::read_time() and heap::keyread_time() adjusted to not add +1. This was to ensure that handler::keyread_time() doesn't give higher cost for heap tables than for normal tables. One effect of this is that heap and derived tables stored in heap will prefer key access as this is now regarded as cheap. - Changed cost for index read in sql_select.cc to match multi_range_read_info_const(). All index cost calculation is now done trough one function. - 'ref' will now use quick_cost for keys if it exists. This is done so that for '=' ranges, 'ref' is prefered over 'range'. - scan_time() now takes avg_io_costs() into account - get_delayed_table_estimates() uses block_size and avg_io_cost() - Removed default argument to test_if_order_by_key(); simplifies code
2020-02-28 12:59:30 +02:00
1 SIMPLE t1 range a a 5 NULL 11 Using where; Using index
select * from t1 where not(a < 15 and a > 5);
a
0
1
2
3
4
5
15
16
17
18
19
explain select * from t1 where a = 2 or not(a < 10);
id select_type table type possible_keys key key_len ref rows Extra
Updated optimizer costs in multi_range_read_info_const() and sql_select.cc - multi_range_read_info_const now uses the new records_in_range interface - Added handler::avg_io_cost() - Don't calculate avg_io_cost() in get_sweep_read_cost if avg_io_cost is not 1.0. In this case we trust the avg_io_cost() from the handler. - Changed test_quick_select to use TIME_FOR_COMPARE instead of TIME_FOR_COMPARE_IDX to align this with the rest of the code. - Fixed bug when using test_if_cheaper_ordering where we didn't use keyread if index was changed - Fixed a bug where we didn't use index only read when using order-by-index - Added keyread_time() to HEAP. The default keyread_time() was optimized for blocks and not suitable for HEAP. The effect was the HEAP prefered table scans over ranges for btree indexes. - Fixed get_sweep_read_cost() for HEAP tables - Ensure that range and ref have same cost for simple ranges Added a small cost (MULTI_RANGE_READ_SETUP_COST) to ranges to ensure we favior ref for range for simple queries. - Fixed that matching_candidates_in_table() uses same number of records as the rest of the optimizer - Added avg_io_cost() to JT_EQ_REF cost. This helps calculate the cost for HEAP and temporary tables better. A few tests changed because of this. - heap::read_time() and heap::keyread_time() adjusted to not add +1. This was to ensure that handler::keyread_time() doesn't give higher cost for heap tables than for normal tables. One effect of this is that heap and derived tables stored in heap will prefer key access as this is now regarded as cheap. - Changed cost for index read in sql_select.cc to match multi_range_read_info_const(). All index cost calculation is now done trough one function. - 'ref' will now use quick_cost for keys if it exists. This is done so that for '=' ranges, 'ref' is prefered over 'range'. - scan_time() now takes avg_io_costs() into account - get_delayed_table_estimates() uses block_size and avg_io_cost() - Removed default argument to test_if_order_by_key(); simplifies code
2020-02-28 12:59:30 +02:00
1 SIMPLE t1 range a a 5 NULL 11 Using where; Using index
select * from t1 where a = 2 or not(a < 10);
a
2
10
11
12
13
14
15
16
17
18
19
explain select * from t1 where a > 5 and not(a > 10);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range a a 5 NULL 5 Using where; Using index
select * from t1 where a > 5 and not(a > 10);
a
6
7
8
9
10
explain select * from t1 where a > 5 xor a < 10;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 index NULL a 5 NULL 21 Using where; Using index
select * from t1 where a > 5 xor a < 10;
a
0
1
2
3
4
5
10
11
12
13
14
15
16
17
18
19
explain select * from t1 where a = 2 or not(a < 5 or a > 15);
id select_type table type possible_keys key key_len ref rows Extra
Updated optimizer costs in multi_range_read_info_const() and sql_select.cc - multi_range_read_info_const now uses the new records_in_range interface - Added handler::avg_io_cost() - Don't calculate avg_io_cost() in get_sweep_read_cost if avg_io_cost is not 1.0. In this case we trust the avg_io_cost() from the handler. - Changed test_quick_select to use TIME_FOR_COMPARE instead of TIME_FOR_COMPARE_IDX to align this with the rest of the code. - Fixed bug when using test_if_cheaper_ordering where we didn't use keyread if index was changed - Fixed a bug where we didn't use index only read when using order-by-index - Added keyread_time() to HEAP. The default keyread_time() was optimized for blocks and not suitable for HEAP. The effect was the HEAP prefered table scans over ranges for btree indexes. - Fixed get_sweep_read_cost() for HEAP tables - Ensure that range and ref have same cost for simple ranges Added a small cost (MULTI_RANGE_READ_SETUP_COST) to ranges to ensure we favior ref for range for simple queries. - Fixed that matching_candidates_in_table() uses same number of records as the rest of the optimizer - Added avg_io_cost() to JT_EQ_REF cost. This helps calculate the cost for HEAP and temporary tables better. A few tests changed because of this. - heap::read_time() and heap::keyread_time() adjusted to not add +1. This was to ensure that handler::keyread_time() doesn't give higher cost for heap tables than for normal tables. One effect of this is that heap and derived tables stored in heap will prefer key access as this is now regarded as cheap. - Changed cost for index read in sql_select.cc to match multi_range_read_info_const(). All index cost calculation is now done trough one function. - 'ref' will now use quick_cost for keys if it exists. This is done so that for '=' ranges, 'ref' is prefered over 'range'. - scan_time() now takes avg_io_costs() into account - get_delayed_table_estimates() uses block_size and avg_io_cost() - Removed default argument to test_if_order_by_key(); simplifies code
2020-02-28 12:59:30 +02:00
1 SIMPLE t1 range a a 5 NULL 12 Using where; Using index
select * from t1 where a = 2 or not(a < 5 or a > 15);
a
2
5
6
7
8
9
10
11
12
13
14
15
explain select * from t1 where a = 7 or not(a < 15 and a > 5);
id select_type table type possible_keys key key_len ref rows Extra
Updated optimizer costs in multi_range_read_info_const() and sql_select.cc - multi_range_read_info_const now uses the new records_in_range interface - Added handler::avg_io_cost() - Don't calculate avg_io_cost() in get_sweep_read_cost if avg_io_cost is not 1.0. In this case we trust the avg_io_cost() from the handler. - Changed test_quick_select to use TIME_FOR_COMPARE instead of TIME_FOR_COMPARE_IDX to align this with the rest of the code. - Fixed bug when using test_if_cheaper_ordering where we didn't use keyread if index was changed - Fixed a bug where we didn't use index only read when using order-by-index - Added keyread_time() to HEAP. The default keyread_time() was optimized for blocks and not suitable for HEAP. The effect was the HEAP prefered table scans over ranges for btree indexes. - Fixed get_sweep_read_cost() for HEAP tables - Ensure that range and ref have same cost for simple ranges Added a small cost (MULTI_RANGE_READ_SETUP_COST) to ranges to ensure we favior ref for range for simple queries. - Fixed that matching_candidates_in_table() uses same number of records as the rest of the optimizer - Added avg_io_cost() to JT_EQ_REF cost. This helps calculate the cost for HEAP and temporary tables better. A few tests changed because of this. - heap::read_time() and heap::keyread_time() adjusted to not add +1. This was to ensure that handler::keyread_time() doesn't give higher cost for heap tables than for normal tables. One effect of this is that heap and derived tables stored in heap will prefer key access as this is now regarded as cheap. - Changed cost for index read in sql_select.cc to match multi_range_read_info_const(). All index cost calculation is now done trough one function. - 'ref' will now use quick_cost for keys if it exists. This is done so that for '=' ranges, 'ref' is prefered over 'range'. - scan_time() now takes avg_io_costs() into account - get_delayed_table_estimates() uses block_size and avg_io_cost() - Removed default argument to test_if_order_by_key(); simplifies code
2020-02-28 12:59:30 +02:00
1 SIMPLE t1 range a a 5 NULL 12 Using where; Using index
select * from t1 where a = 7 or not(a < 15 and a > 5);
a
0
1
2
3
4
5
7
15
16
17
18
19
explain select * from t1 where NULL or not(a < 15 and a > 5);
id select_type table type possible_keys key key_len ref rows Extra
Updated optimizer costs in multi_range_read_info_const() and sql_select.cc - multi_range_read_info_const now uses the new records_in_range interface - Added handler::avg_io_cost() - Don't calculate avg_io_cost() in get_sweep_read_cost if avg_io_cost is not 1.0. In this case we trust the avg_io_cost() from the handler. - Changed test_quick_select to use TIME_FOR_COMPARE instead of TIME_FOR_COMPARE_IDX to align this with the rest of the code. - Fixed bug when using test_if_cheaper_ordering where we didn't use keyread if index was changed - Fixed a bug where we didn't use index only read when using order-by-index - Added keyread_time() to HEAP. The default keyread_time() was optimized for blocks and not suitable for HEAP. The effect was the HEAP prefered table scans over ranges for btree indexes. - Fixed get_sweep_read_cost() for HEAP tables - Ensure that range and ref have same cost for simple ranges Added a small cost (MULTI_RANGE_READ_SETUP_COST) to ranges to ensure we favior ref for range for simple queries. - Fixed that matching_candidates_in_table() uses same number of records as the rest of the optimizer - Added avg_io_cost() to JT_EQ_REF cost. This helps calculate the cost for HEAP and temporary tables better. A few tests changed because of this. - heap::read_time() and heap::keyread_time() adjusted to not add +1. This was to ensure that handler::keyread_time() doesn't give higher cost for heap tables than for normal tables. One effect of this is that heap and derived tables stored in heap will prefer key access as this is now regarded as cheap. - Changed cost for index read in sql_select.cc to match multi_range_read_info_const(). All index cost calculation is now done trough one function. - 'ref' will now use quick_cost for keys if it exists. This is done so that for '=' ranges, 'ref' is prefered over 'range'. - scan_time() now takes avg_io_costs() into account - get_delayed_table_estimates() uses block_size and avg_io_cost() - Removed default argument to test_if_order_by_key(); simplifies code
2020-02-28 12:59:30 +02:00
1 SIMPLE t1 range a a 5 NULL 11 Using where; Using index
select * from t1 where NULL or not(a < 15 and a > 5);
a
0
1
2
3
4
5
15
16
17
18
19
explain select * from t1 where not(NULL and a > 5);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range a a 5 NULL 6 Using where; Using index
select * from t1 where not(NULL and a > 5);
a
0
1
2
3
4
5
explain select * from t1 where not(NULL or a);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE NULL NULL NULL NULL NULL NULL NULL Impossible WHERE
select * from t1 where not(NULL or a);
a
explain select * from t1 where not(NULL and a);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 ref a a 5 const 1 Using index
select * from t1 where not(NULL and a);
a
0
explain select * from t1 where not((a < 5 or a < 10) and (not(a > 16) or a > 17));
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range a a 5 NULL 10 Using where; Using index
select * from t1 where not((a < 5 or a < 10) and (not(a > 16) or a > 17));
a
10
11
12
13
14
15
16
17
18
19
explain select * from t1 where not((a < 5 and a < 10) and (not(a > 16) or a > 17));
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range a a 5 NULL 15 Using where; Using index
select * from t1 where not((a < 5 and a < 10) and (not(a > 16) or a > 17));
a
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
explain select * from t1 where ((a between 5 and 15) and (not(a like 10)));
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range a a 5 NULL 11 Using where; Using index
select * from t1 where ((a between 5 and 15) and (not(a like 10)));
a
5
6
7
8
9
11
12
13
14
15
Port of code for: (part of testcase is in mysql-test/t/subquery*.test and will be ported separately) Bug#11766642: crash in Item_field::register_field_in_read_map with view (Former 59793) Prior to the refactoring in this patch, Item_cond_xor behaved partially as an Item_cond and partially as an Item_func. The reasoning behind this was that XOR is currently not optimized (thus should be Item_func instead of Item_cond), but it was planned optimize it in the future (thus, made Item_cond anyway to ease optimization later). Even though Item_cond inherits from Item_func, there are differences between these two. One difference is that the arguments are stored differently. Item_cond stores them in a list while Item_func store them in an args[]. BUG no 45221 was caused by Item_cond_xor storing arguments in the list while users of the objects would look for them in args[]. The fix back then was to store the arguments in both locations. In this bug, Item_cond_xor initially gets two Item_field arguments. These are stored in the list inherited from Item_cond and in args[] inherited from Item_func. During resolution, find_field_in_view() replaces the Item_fields stored in the list with Item_direct_view_refs, but args[] still points to the unresolved Item_fields. This shows that the fix for 45221 was incorrect. The refactoring performed in this patch removes the confusion by making the XOR item an Item_func period. A neg_transformer() is also implemented for Item_func_xor to improve performance when negating XOR expressions. An XOR is negated by negating one of the operands.
2011-07-11 23:48:35 +04:00
# XOR (Note: XOR is negated by negating one of the operands)
# Should return 6,7
SELECT * FROM t1 WHERE ((a > 5) XOR (a > 7));
a
6
7
# Should return 0..5,8..19
SELECT * FROM t1 WHERE ((NOT (a > 5)) XOR (a > 7));
a
0
1
2
3
4
5
8
9
10
11
12
13
14
15
16
17
18
19
SELECT * FROM t1 WHERE ((a > 5) XOR (NOT (a > 7)));
a
0
1
2
3
4
5
8
9
10
11
12
13
14
15
16
17
18
19
SELECT * FROM t1 WHERE NOT ((a > 5) XOR (a > 7));
a
0
1
2
3
4
5
8
9
10
11
12
13
14
15
16
17
18
19
# Should return 6,7
SELECT * FROM t1 WHERE NOT ((NOT (a > 5)) XOR (a > 7));
a
6
7
SELECT * FROM t1 WHERE NOT ((a > 5) XOR (NOT (a > 7)));
a
6
7
# Should return 0..5,8..19
SELECT * FROM t1 WHERE NOT ((NOT (a > 5)) XOR (NOT (a > 7)));
a
0
1
2
3
4
5
8
9
10
11
12
13
14
15
16
17
18
19
# Should have empty result
SELECT * FROM t1 WHERE (NULL XOR (a > 7));
a
SELECT * FROM t1 WHERE NOT (NULL XOR (a > 7));
a
# Should be simplified to "...WHERE (a XOR a)
EXPLAIN EXTENDED SELECT * FROM t1 WHERE NOT ((NOT a) XOR (a));
id select_type table type possible_keys key key_len ref rows filtered Extra
1 SIMPLE t1 index NULL a 5 NULL 21 100.00 Using where; Using index
Warnings:
Note 1003 select `test`.`t1`.`a` AS `a` from `test`.`t1` where `test`.`t1`.`a` xor `test`.`t1`.`a`
Port of code for: (part of testcase is in mysql-test/t/subquery*.test and will be ported separately) Bug#11766642: crash in Item_field::register_field_in_read_map with view (Former 59793) Prior to the refactoring in this patch, Item_cond_xor behaved partially as an Item_cond and partially as an Item_func. The reasoning behind this was that XOR is currently not optimized (thus should be Item_func instead of Item_cond), but it was planned optimize it in the future (thus, made Item_cond anyway to ease optimization later). Even though Item_cond inherits from Item_func, there are differences between these two. One difference is that the arguments are stored differently. Item_cond stores them in a list while Item_func store them in an args[]. BUG no 45221 was caused by Item_cond_xor storing arguments in the list while users of the objects would look for them in args[]. The fix back then was to store the arguments in both locations. In this bug, Item_cond_xor initially gets two Item_field arguments. These are stored in the list inherited from Item_cond and in args[] inherited from Item_func. During resolution, find_field_in_view() replaces the Item_fields stored in the list with Item_direct_view_refs, but args[] still points to the unresolved Item_fields. This shows that the fix for 45221 was incorrect. The refactoring performed in this patch removes the confusion by making the XOR item an Item_func period. A neg_transformer() is also implemented for Item_func_xor to improve performance when negating XOR expressions. An XOR is negated by negating one of the operands.
2011-07-11 23:48:35 +04:00
# Should be simplified to "...WHERE (a XOR a)
EXPLAIN EXTENDED SELECT * FROM t1 WHERE NOT (a XOR (NOT a));
id select_type table type possible_keys key key_len ref rows filtered Extra
1 SIMPLE t1 index NULL a 5 NULL 21 100.00 Using where; Using index
Warnings:
Note 1003 select `test`.`t1`.`a` AS `a` from `test`.`t1` where `test`.`t1`.`a` xor `test`.`t1`.`a`
Port of code for: (part of testcase is in mysql-test/t/subquery*.test and will be ported separately) Bug#11766642: crash in Item_field::register_field_in_read_map with view (Former 59793) Prior to the refactoring in this patch, Item_cond_xor behaved partially as an Item_cond and partially as an Item_func. The reasoning behind this was that XOR is currently not optimized (thus should be Item_func instead of Item_cond), but it was planned optimize it in the future (thus, made Item_cond anyway to ease optimization later). Even though Item_cond inherits from Item_func, there are differences between these two. One difference is that the arguments are stored differently. Item_cond stores them in a list while Item_func store them in an args[]. BUG no 45221 was caused by Item_cond_xor storing arguments in the list while users of the objects would look for them in args[]. The fix back then was to store the arguments in both locations. In this bug, Item_cond_xor initially gets two Item_field arguments. These are stored in the list inherited from Item_cond and in args[] inherited from Item_func. During resolution, find_field_in_view() replaces the Item_fields stored in the list with Item_direct_view_refs, but args[] still points to the unresolved Item_fields. This shows that the fix for 45221 was incorrect. The refactoring performed in this patch removes the confusion by making the XOR item an Item_func period. A neg_transformer() is also implemented for Item_func_xor to improve performance when negating XOR expressions. An XOR is negated by negating one of the operands.
2011-07-11 23:48:35 +04:00
# End XOR
delete from t1 where a > 3;
select a, not(not(a)) from t1;
a not(not(a))
NULL NULL
0 0
1 1
2 1
3 1
explain extended select a, not(not(a)), not(a <= 2 and not(a)), not(a not like "1"), not (a not in (1,2)), not(a != 2) from t1 where not(not(a)) having not(not(a));
BUG#14940 "MySQL choose wrong index", v.2 - Make the range-et-al optimizer produce E(#table records after table condition is applied), - Make the join optimizer use this value, - Add "filtered" column to EXPLAIN EXTENDED to show fraction of records left after table condition is applied - Adjust test results, add comments mysql-test/r/archive_gis.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/auto_increment.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/bdb_gis.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/bench_count_distinct.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/binlog_stm_blackhole.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/case.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/cast.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/compress.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/ctype_collate.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/ctype_cp1250_ch.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/date_formats.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/distinct.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/fulltext.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/func_compress.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/func_crypt.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/func_default.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/func_encrypt.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/func_gconcat.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/func_group.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/func_if.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/func_in.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/func_like.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/func_math.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/func_op.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/func_regexp.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/func_set.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/func_str.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/func_system.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/func_test.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/func_time.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/gis.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/group_by.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/group_min_max.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/having.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/heap.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/heap_hash.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/index_merge.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/index_merge_innodb.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/index_merge_ror.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/innodb_gis.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/insert_update.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/join.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/join_nested.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/key_diff.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/myisam.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/ndb_gis.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/negation_elimination.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/null.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/olap.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/partition_pruning.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/query_cache.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/row.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/rpl_get_lock.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/rpl_master_pos_wait.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/select.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/ssl.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/ssl_compress.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/subselect.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/type_blob.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/union.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/varbinary.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/variables.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/r/view.result: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/t/ctype_cp1250_ch.test: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/t/func_like.test: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/t/group_min_max.test: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/t/index_merge_ror.test: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/t/index_merge_ror_cpk.test: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/t/join.test: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column mysql-test/t/partition_pruning.test: BUG#14940: Adjust the test results: EXPLAIN EXTENDED now has extra "filtered" column sql/opt_range.cc: BUG#14940: Make range/index_merge/group-min-max optimizer produce TABLE::quick_condition_rows - estimate of #records that will match the table condition. sql/sql_class.cc: BUG#14940: Add "filtered" column to output of EXPLAIN EXTENDED sql/sql_select.cc: BUG#14940: - Make the join optimizer to use TABLE::quick_condition_rows= = E(#table records after filtering with table condition) - Add "filtered" column to output of EXPLAIN EXTENDED sql/sql_select.h: BUG#14940: Added comments sql/table.h: BUG#14940: Added comments
2006-07-28 21:27:01 +04:00
id select_type table type possible_keys key key_len ref rows filtered Extra
Updated optimizer costs in multi_range_read_info_const() and sql_select.cc - multi_range_read_info_const now uses the new records_in_range interface - Added handler::avg_io_cost() - Don't calculate avg_io_cost() in get_sweep_read_cost if avg_io_cost is not 1.0. In this case we trust the avg_io_cost() from the handler. - Changed test_quick_select to use TIME_FOR_COMPARE instead of TIME_FOR_COMPARE_IDX to align this with the rest of the code. - Fixed bug when using test_if_cheaper_ordering where we didn't use keyread if index was changed - Fixed a bug where we didn't use index only read when using order-by-index - Added keyread_time() to HEAP. The default keyread_time() was optimized for blocks and not suitable for HEAP. The effect was the HEAP prefered table scans over ranges for btree indexes. - Fixed get_sweep_read_cost() for HEAP tables - Ensure that range and ref have same cost for simple ranges Added a small cost (MULTI_RANGE_READ_SETUP_COST) to ranges to ensure we favior ref for range for simple queries. - Fixed that matching_candidates_in_table() uses same number of records as the rest of the optimizer - Added avg_io_cost() to JT_EQ_REF cost. This helps calculate the cost for HEAP and temporary tables better. A few tests changed because of this. - heap::read_time() and heap::keyread_time() adjusted to not add +1. This was to ensure that handler::keyread_time() doesn't give higher cost for heap tables than for normal tables. One effect of this is that heap and derived tables stored in heap will prefer key access as this is now regarded as cheap. - Changed cost for index read in sql_select.cc to match multi_range_read_info_const(). All index cost calculation is now done trough one function. - 'ref' will now use quick_cost for keys if it exists. This is done so that for '=' ranges, 'ref' is prefered over 'range'. - scan_time() now takes avg_io_costs() into account - get_delayed_table_estimates() uses block_size and avg_io_cost() - Removed default argument to test_if_order_by_key(); simplifies code
2020-02-28 12:59:30 +02:00
1 SIMPLE t1 range a a 5 NULL 4 100.00 Using where; Using index
Warnings:
Note 1003 select `test`.`t1`.`a` AS `a`,`test`.`t1`.`a` <> 0 AS `not(not(a))`,`test`.`t1`.`a` > 2 or `test`.`t1`.`a` <> 0 AS `not(a <= 2 and not(a))`,`test`.`t1`.`a` like '1' AS `not(a not like "1")`,`test`.`t1`.`a` in (1,2) AS `not (a not in (1,2))`,`test`.`t1`.`a` = 2 AS `not(a != 2)` from `test`.`t1` where `test`.`t1`.`a` <> 0 having `test`.`t1`.`a` <> 0
drop table t1;