mirror/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-01-31 02:51:44 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
mariadb/mysql-test/main/range_aria_dbt3.result

26 lines
1.1 KiB
Text
Raw Normal View History

MDEV-30325 Wrong result upon range query using index condition wrong result upon range query using index condition This was caused by a bug in key_or() when SEL_ARG* key1 has been cloned and is overlapping with SEL_ARG *key2 Cloning of SEL_ARG's happens only in very special cases, which is why this bug has remained undetected for years. It happend in the following query: SELECT COUNT(*) FROM lineitem force index (i_l_orderkey_quantity,i_l_shipdate) WHERE l_shipdate < '1994-01-01' AND l_orderkey < 800 OR l_quantity > 3 AND l_orderkey NOT IN ( 157, 1444 ); Because there are two different indexes that can be used and the code for IN causes a 'tree_or', which causes all SEL_ARG's to be cloned. Other things: - While checking the code, I found a bug in SEL_ARG::SEL_ARG(SEL_ARG &arg) - This was incrementing next_key_part->use_count as part of creating a copy of an existing SEL_ARG. This is however not enough as the 'reverse operation' when the copy is not needed is 'key2_cpy.increment_use_count(-1)', which does something completely different. Fixed by calling increment_use_count(1) in SEL_ARG::SEL_ARG.
2023-01-04 19:16:45 +02:00
set default_storage_engine=Aria;
CREATE DATABASE dbt3_s001;
use dbt3_s001;
#
# MDEV-30325 Wrong result upon range query using index condition
#
SELECT COUNT(*) FROM lineitem force index (i_l_orderkey_quantity,i_l_shipdate) WHERE l_shipdate < '1994-01-01' AND l_orderkey < 800 OR l_quantity > 3 AND l_orderkey NOT IN ( 157, 1444 );
COUNT(*)
MDEV-30373 Wrong result with range access This issue was caused by the bug fix for MDEV-30325 Wrong result upon range query using index condition The bug could happen in the case of several overlapping key ranges with OR
2023-01-11 18:12:40 +02:00
5658
SELECT COUNT(*) FROM lineitem ignore index (i_l_orderkey_quantity,i_l_shipdate) WHERE l_shipdate < '1994-01-01' AND l_orderkey < 800 OR l_quantity > 3 AND l_orderkey NOT IN ( 157, 1444 );
COUNT(*)
5658
MDEV-30325 Wrong result upon range query using index condition wrong result upon range query using index condition This was caused by a bug in key_or() when SEL_ARG* key1 has been cloned and is overlapping with SEL_ARG *key2 Cloning of SEL_ARG's happens only in very special cases, which is why this bug has remained undetected for years. It happend in the following query: SELECT COUNT(*) FROM lineitem force index (i_l_orderkey_quantity,i_l_shipdate) WHERE l_shipdate < '1994-01-01' AND l_orderkey < 800 OR l_quantity > 3 AND l_orderkey NOT IN ( 157, 1444 ); Because there are two different indexes that can be used and the code for IN causes a 'tree_or', which causes all SEL_ARG's to be cloned. Other things: - While checking the code, I found a bug in SEL_ARG::SEL_ARG(SEL_ARG &arg) - This was incrementing next_key_part->use_count as part of creating a copy of an existing SEL_ARG. This is however not enough as the 'reverse operation' when the copy is not needed is 'key2_cpy.increment_use_count(-1)', which does something completely different. Fixed by calling increment_use_count(1) in SEL_ARG::SEL_ARG.
2023-01-04 19:16:45 +02:00
#
MDEV-30373 Wrong result with range access This issue was caused by the bug fix for MDEV-30325 Wrong result upon range query using index condition The bug could happen in the case of several overlapping key ranges with OR
2023-01-11 18:12:40 +02:00
# MDEV-30373 Wrong result with range access
MDEV-30325 Wrong result upon range query using index condition wrong result upon range query using index condition This was caused by a bug in key_or() when SEL_ARG* key1 has been cloned and is overlapping with SEL_ARG *key2 Cloning of SEL_ARG's happens only in very special cases, which is why this bug has remained undetected for years. It happend in the following query: SELECT COUNT(*) FROM lineitem force index (i_l_orderkey_quantity,i_l_shipdate) WHERE l_shipdate < '1994-01-01' AND l_orderkey < 800 OR l_quantity > 3 AND l_orderkey NOT IN ( 157, 1444 ); Because there are two different indexes that can be used and the code for IN causes a 'tree_or', which causes all SEL_ARG's to be cloned. Other things: - While checking the code, I found a bug in SEL_ARG::SEL_ARG(SEL_ARG &arg) - This was incrementing next_key_part->use_count as part of creating a copy of an existing SEL_ARG. This is however not enough as the 'reverse operation' when the copy is not needed is 'key2_cpy.increment_use_count(-1)', which does something completely different. Fixed by calling increment_use_count(1) in SEL_ARG::SEL_ARG.
2023-01-04 19:16:45 +02:00
#
MDEV-30373 Wrong result with range access This issue was caused by the bug fix for MDEV-30325 Wrong result upon range query using index condition The bug could happen in the case of several overlapping key ranges with OR
2023-01-11 18:12:40 +02:00
explain SELECT COUNT(*) FROM lineitem WHERE l_orderkey BETWEEN 111 AND 262 OR ( l_orderkey BETWEEN 152 AND 672 AND l_linenumber BETWEEN 4 AND 9 );
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE lineitem range PRIMARY,i_l_orderkey,i_l_orderkey_quantity PRIMARY 8 NULL 506 Using where; Using index
SELECT COUNT(*) FROM lineitem WHERE l_orderkey BETWEEN 111 AND 262 OR ( l_orderkey BETWEEN 152 AND 672 AND l_linenumber BETWEEN 4 AND 9 );
COUNT(*)
293
MDEV-30325 Wrong result upon range query using index condition wrong result upon range query using index condition This was caused by a bug in key_or() when SEL_ARG* key1 has been cloned and is overlapping with SEL_ARG *key2 Cloning of SEL_ARG's happens only in very special cases, which is why this bug has remained undetected for years. It happend in the following query: SELECT COUNT(*) FROM lineitem force index (i_l_orderkey_quantity,i_l_shipdate) WHERE l_shipdate < '1994-01-01' AND l_orderkey < 800 OR l_quantity > 3 AND l_orderkey NOT IN ( 157, 1444 ); Because there are two different indexes that can be used and the code for IN causes a 'tree_or', which causes all SEL_ARG's to be cloned. Other things: - While checking the code, I found a bug in SEL_ARG::SEL_ARG(SEL_ARG &arg) - This was incrementing next_key_part->use_count as part of creating a copy of an existing SEL_ARG. This is however not enough as the 'reverse operation' when the copy is not needed is 'key2_cpy.increment_use_count(-1)', which does something completely different. Fixed by calling increment_use_count(1) in SEL_ARG::SEL_ARG.
2023-01-04 19:16:45 +02:00
DROP DATABASE dbt3_s001;
MDEV-30373 Wrong result with range access This issue was caused by the bug fix for MDEV-30325 Wrong result upon range query using index condition The bug could happen in the case of several overlapping key ranges with OR
2023-01-11 18:12:40 +02:00
#
# End of 10.5 tests
#
Reference in a new issue Copy permalink