mirror/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-01-16 03:52:35 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
mariadb/mysql-test/main/range_innodb.test

250 lines
13 KiB
Text
Raw Normal View History

MDEV-6735: Range checked for each record used with key (also MDEV-7786, MDEV-7923) "Range Checked for Each Record" should be only employed when the other option would be cross-product join (i.e. the other option is so bad that we hardly risk anything). Previous logic was: use RCfER if there are no possible quick selects, or quick select would read > 100 rows. Also, it didn't always work as expected due to range optimizer changing table->quick_keys and us looking at sel->quick_keys. Another angle is that recent versions have enabled use of Join Buffering in e.g. outer joins. This further reduces the range of cases where RCfER should be used. We are still unable to estimate the cost of RCfER with any precision, so now changing the condition of "no quick select or quick->records> 100" to a hopefully better condition "no quick select or quick would cost more than full table scan".
2015-06-09 17:56:09 +02:00
--echo #
--echo # Range optimizer (and related) tests that need InnoDB.
--echo #
--source include/have_innodb.inc
MDEV-14440: Assertion `inited==RND' failed in handler::ha_rnd_end In the function QUICK_RANGE_SELECT::init_ror_merged_scan we create a seperate handler if the handler in head->file cannot be reused. The flag free_file tells us if we have a seperate handler or not. There are cases where you might create a handler and then there might be a failure(running ALTER) and then we have to revert the handler back to the original one. The code does that but it does not reset the flag 'free_file' in this case. Also backported f2c418079def.
2019-01-17 21:56:12 +01:00
--source include/have_debug.inc
Work around MDEV-24813 in some tests Not creating explicit record locks will speed up the test. Also, disable the use of InnoDB persistent statistics in the test of MDEV-27270 to avoid intermittent failures in 10.6 or later (after commit 9608773f75e2ca21491ef6825c3616cdc96d1ca5) due to the nondeterministic scheduling of STATS_AUTO_PERSISTENT.
2022-11-08 08:00:58 +01:00
--source include/have_sequence.inc
Disable valgrind for test in main that takes > 200 seconds One can run these with --valgrind --big
2022-10-04 10:26:50 +02:00
--source include/no_valgrind_without_big.inc
MDEV-6735: Range checked for each record used with key (also MDEV-7786, MDEV-7923) "Range Checked for Each Record" should be only employed when the other option would be cross-product join (i.e. the other option is so bad that we hardly risk anything). Previous logic was: use RCfER if there are no possible quick selects, or quick select would read > 100 rows. Also, it didn't always work as expected due to range optimizer changing table->quick_keys and us looking at sel->quick_keys. Another angle is that recent versions have enabled use of Join Buffering in e.g. outer joins. This further reduces the range of cases where RCfER should be used. We are still unable to estimate the cost of RCfER with any precision, so now changing the condition of "no quick select or quick->records> 100" to a hopefully better condition "no quick select or quick would cost more than full table scan".
2015-06-09 17:56:09 +02:00
--echo #
--echo # MDEV-6735: Range checked for each record used with key
--echo #
create table t0(a int);
insert into t0 values (0),(1),(2),(3),(4),(5),(6),(7),(8),(9);
create table t2 (
a int,
b int,
filler1 char(100),
filler2 char(100),
filler3 char(100),
filler4 char(100),
key(a),
key(b)
) engine=innodb;
insert into t2
select
Work around MDEV-24813 in some tests Not creating explicit record locks will speed up the test. Also, disable the use of InnoDB persistent statistics in the test of MDEV-27270 to avoid intermittent failures in 10.6 or later (after commit 9608773f75e2ca21491ef6825c3616cdc96d1ca5) due to the nondeterministic scheduling of STATS_AUTO_PERSISTENT.
2022-11-08 08:00:58 +01:00
seq,seq,
MDEV-6735: Range checked for each record used with key (also MDEV-7786, MDEV-7923) "Range Checked for Each Record" should be only employed when the other option would be cross-product join (i.e. the other option is so bad that we hardly risk anything). Previous logic was: use RCfER if there are no possible quick selects, or quick select would read > 100 rows. Also, it didn't always work as expected due to range optimizer changing table->quick_keys and us looking at sel->quick_keys. Another angle is that recent versions have enabled use of Join Buffering in e.g. outer joins. This further reduces the range of cases where RCfER should be used. We are still unable to estimate the cost of RCfER with any precision, so now changing the condition of "no quick select or quick->records> 100" to a hopefully better condition "no quick select or quick would cost more than full table scan".
2015-06-09 17:56:09 +02:00
repeat('0123456789', 10),
repeat('0123456789', 10),
repeat('0123456789', 10),
repeat('0123456789', 10)
Work around MDEV-24813 in some tests Not creating explicit record locks will speed up the test. Also, disable the use of InnoDB persistent statistics in the test of MDEV-27270 to avoid intermittent failures in 10.6 or later (after commit 9608773f75e2ca21491ef6825c3616cdc96d1ca5) due to the nondeterministic scheduling of STATS_AUTO_PERSISTENT.
2022-11-08 08:00:58 +01:00
from seq_0_to_9999;
MDEV-6735: Range checked for each record used with key (also MDEV-7786, MDEV-7923) "Range Checked for Each Record" should be only employed when the other option would be cross-product join (i.e. the other option is so bad that we hardly risk anything). Previous logic was: use RCfER if there are no possible quick selects, or quick select would read > 100 rows. Also, it didn't always work as expected due to range optimizer changing table->quick_keys and us looking at sel->quick_keys. Another angle is that recent versions have enabled use of Join Buffering in e.g. outer joins. This further reduces the range of cases where RCfER should be used. We are still unable to estimate the cost of RCfER with any precision, so now changing the condition of "no quick select or quick->records> 100" to a hopefully better condition "no quick select or quick would cost more than full table scan".
2015-06-09 17:56:09 +02:00
analyze table t2;
--echo # The following must not use "Range checked for each record":
explain select * from t0 left join t2 on t2.a <t0.a and t2.b between 50 and 250;
Work around MDEV-24813 in some tests Not creating explicit record locks will speed up the test. Also, disable the use of InnoDB persistent statistics in the test of MDEV-27270 to avoid intermittent failures in 10.6 or later (after commit 9608773f75e2ca21491ef6825c3616cdc96d1ca5) due to the nondeterministic scheduling of STATS_AUTO_PERSISTENT.
2022-11-08 08:00:58 +01:00
drop table t0,t2;
MDEV-6735: Range checked for each record used with key (also MDEV-7786, MDEV-7923) "Range Checked for Each Record" should be only employed when the other option would be cross-product join (i.e. the other option is so bad that we hardly risk anything). Previous logic was: use RCfER if there are no possible quick selects, or quick select would read > 100 rows. Also, it didn't always work as expected due to range optimizer changing table->quick_keys and us looking at sel->quick_keys. Another angle is that recent versions have enabled use of Join Buffering in e.g. outer joins. This further reduces the range of cases where RCfER should be used. We are still unable to estimate the cost of RCfER with any precision, so now changing the condition of "no quick select or quick->records> 100" to a hopefully better condition "no quick select or quick would cost more than full table scan".
2015-06-09 17:56:09 +02:00
MDEV-10466 Server crashed in SEL_ARG::store_min() with extended_keys=on This bug could manifest itself in a very rare cases when the optimizer chose an execution plan by which a joined table was accessed by a table scan and the optimizer was checking whether ranges checked for each record could improve this plan. In such cases the optimizer evaluates range conditions over a table that depend on other tables. For such conditions the constructed SEL_ARG trees are marked as MAYBE_KEY. If a SEL_ARG object constructed for a sargable condition marked as RANGE_KEY had the same first key part as a MAYBE_KEY SEL_ARG object and the key_and() function was called for this pair of SEL_ARG objects then an invalid SEL_ARG object could be constructed that ultimately could lead to a crash before the execution phase.
2020-03-15 03:58:57 +01:00
--echo #
--echo # MDEV-10466: constructing an invalid SEL_ARG
--echo #
create table t1 (
pk int, a int, b int,
primary key (pk), index idx1(b), index idx2(b)
MDEV-10003 main.range_innodb retuns a wrong number of rows in EXPLAIN Let us specify STATS_AUTO_RECALC=0 for the failing section of the test. It is possible that this test started failing sporadically ever since commit 9608773f75e2ca21491ef6825c3616cdc96d1ca5 was applied and tests no longer globally disable the InnoDB persistent statistics.
2022-09-07 10:58:04 +02:00
) engine=innodb STATS_AUTO_RECALC=0;
MDEV-10466 Server crashed in SEL_ARG::store_min() with extended_keys=on This bug could manifest itself in a very rare cases when the optimizer chose an execution plan by which a joined table was accessed by a table scan and the optimizer was checking whether ranges checked for each record could improve this plan. In such cases the optimizer evaluates range conditions over a table that depend on other tables. For such conditions the constructed SEL_ARG trees are marked as MAYBE_KEY. If a SEL_ARG object constructed for a sargable condition marked as RANGE_KEY had the same first key part as a MAYBE_KEY SEL_ARG object and the key_and() function was called for this pair of SEL_ARG objects then an invalid SEL_ARG object could be constructed that ultimately could lead to a crash before the execution phase.
2020-03-15 03:58:57 +01:00
insert into t1 values (1,6,0),(2,1,0),(3,5,2),(4,8,0);
MDEV-10003 main.range_innodb retuns a wrong number of rows in EXPLAIN Let us specify STATS_AUTO_RECALC=0 for the failing section of the test. It is possible that this test started failing sporadically ever since commit 9608773f75e2ca21491ef6825c3616cdc96d1ca5 was applied and tests no longer globally disable the InnoDB persistent statistics.
2022-09-07 10:58:04 +02:00
create table t2 (c int) engine=innodb STATS_AUTO_RECALC=0;
MDEV-10466 Server crashed in SEL_ARG::store_min() with extended_keys=on This bug could manifest itself in a very rare cases when the optimizer chose an execution plan by which a joined table was accessed by a table scan and the optimizer was checking whether ranges checked for each record could improve this plan. In such cases the optimizer evaluates range conditions over a table that depend on other tables. For such conditions the constructed SEL_ARG trees are marked as MAYBE_KEY. If a SEL_ARG object constructed for a sargable condition marked as RANGE_KEY had the same first key part as a MAYBE_KEY SEL_ARG object and the key_and() function was called for this pair of SEL_ARG objects then an invalid SEL_ARG object could be constructed that ultimately could lead to a crash before the execution phase.
2020-03-15 03:58:57 +01:00
insert into t2 values (1),(2);
MDEV-10003 main.range_innodb retuns a wrong number of rows in EXPLAIN Let us specify STATS_AUTO_RECALC=0 for the failing section of the test. It is possible that this test started failing sporadically ever since commit 9608773f75e2ca21491ef6825c3616cdc96d1ca5 was applied and tests no longer globally disable the InnoDB persistent statistics.
2022-09-07 10:58:04 +02:00
create table t3 (d int) engine=innodb STATS_AUTO_RECALC=0;
MDEV-10466 Server crashed in SEL_ARG::store_min() with extended_keys=on This bug could manifest itself in a very rare cases when the optimizer chose an execution plan by which a joined table was accessed by a table scan and the optimizer was checking whether ranges checked for each record could improve this plan. In such cases the optimizer evaluates range conditions over a table that depend on other tables. For such conditions the constructed SEL_ARG trees are marked as MAYBE_KEY. If a SEL_ARG object constructed for a sargable condition marked as RANGE_KEY had the same first key part as a MAYBE_KEY SEL_ARG object and the key_and() function was called for this pair of SEL_ARG objects then an invalid SEL_ARG object could be constructed that ultimately could lead to a crash before the execution phase.
2020-03-15 03:58:57 +01:00
insert into t3 values (3),(-1),(4);
set @save_optimizer_switch=@@optimizer_switch;
set optimizer_switch='extended_keys=on';
Update row and key fetch cost models to take into account data copy costs Before this patch, when calculating the cost of fetching and using a row/key from the engine, we took into account the cost of finding a row or key from the engine, but did not consistently take into account index only accessed, clustered key or covered keys for all access paths. The cost of the WHERE clause (TIME_FOR_COMPARE) was not consistently considered in best_access_path(). TIME_FOR_COMPARE was used in calculation in other places, like greedy_search(), but was in some cases (like scans) done an a different number of rows than was accessed. The cost calculation of row and index scans didn't take into account the number of rows that where accessed, only the number of accepted rows. When using a filter, the cost of index_only_reads and cost of accessing and disregarding 'filtered rows' where not taken into account, which made filters cost less than there actually where. To remedy the above, the following key & row fetch related costs has been added: - The cost of fetching and using a row is now split into different costs: - key + Row fetch cost (as before) but multiplied with the variable 'optimizer_cache_cost' (default to 0.5). This allows the user to tell the optimizer the likehood of finding the key and row in the engine cache. - ROW_COPY_COST, The cost copying a row from the engine to the sql layer or creating a row from the join_cache to the record buffer. Mostly affects table scan costs. - ROW_LOOKUP_COST, the cost of fetching a row by rowid. - KEY_COPY_COST the cost of finding the next key and copying it from the engine to the SQL layer. This is used when we calculate the cost index only reads. It makes index scans more expensive than before if they cover a lot of rows. (main.index_merge_myisam) - KEY_LOOKUP_COST, the cost of finding the first key in a range. This replaces the old define IDX_LOOKUP_COST, but with a higher cost. - KEY_NEXT_FIND_COST, the cost of finding the next key (and rowid). when doing a index scan and comparing the rowid to the filter. Before this cost was assumed to be 0. All of the above constants/variables are now tuned to be somewhat in proportion of executing complexity to each other. There is tuning need for these in the future, but that can wait until the above are made user variables as that will make tuning much easier. To make the usage of the above easy, there are new (not virtual) cost calclation functions in handler: - ha_read_time(), like read_time(), but take optimizer_cache_cost into account. - ha_read_and_copy_time(), like ha_read_time() but take into account ROW_COPY_TIME - ha_read_and_compare_time(), like ha_read_and_copy_time() but take TIME_FOR_COMPARE into account. - ha_rnd_pos_time(). Read row with row id, taking ROW_COPY_COST into account. This is used with filesort where we don't need to execute the WHERE clause again. - ha_keyread_time(), like keyread_time() but take optimizer_cache_cost into account. - ha_keyread_and_copy_time(), like ha_keyread_time(), but add KEY_COPY_COST. - ha_key_scan_time(), like key_scan_time() but take optimizer_cache_cost nto account. - ha_key_scan_and_compare_time(), like ha_key_scan_time(), but add KEY_COPY_COST & TIME_FOR_COMPARE. I also added some setup costs for doing different types of scans and creating temporary tables (on disk and in memory). This encourages the optimizer to not use these for simple 'a few row' lookups if there are adequate key lookup strategies. - TABLE_SCAN_SETUP_COST, cost of starting a table scan. - INDEX_SCAN_SETUP_COST, cost of starting an index scan. - HEAP_TEMPTABLE_CREATE_COST, cost of creating in memory temporary table. - DISK_TEMPTABLE_CREATE_COST, cost of creating an on disk temporary table. When calculating cost of fetching ranges, we had a cost of IDX_LOOKUP_COST (0.125) for doing a key div for a new range. This is now replaced with 'io_cost * KEY_LOOKUP_COST (1.0) * optimizer_cache_cost', which matches the cost we use for 'ref' and other key lookups. The effect is that the cost is now a bit higher when we have many ranges for a key. Allmost all calculation with TIME_FOR_COMPARE is now done in best_access_path(). 'JOIN::read_time' now includes the full cost for finding the rows in the table. In the result files, many of the changes are now again close to what they where before the "Update cost for hash and cached joins" commit, as that commit didn't fix the filter cost (too complex to do everything in one commit). The above changes showed a lot of a lot of inconsistencies in optimizer cost calculation. The main objective with the other changes was to do calculation as similar (and accurate) as possible and to make different plans more comparable. Detailed list of changes: - Calculate index_only_cost consistently and correctly for all scan and ref accesses. The row fetch_cost and index_only_cost now takes into account clustered keys, covered keys and index only accesses. - cost_for_index_read now returns both full cost and index_only_cost - Fixed cost calculation of get_sweep_read_cost() to match other similar costs. This is bases on the assumption that data is more often stored on SSD than a hard disk. - Replaced constant 2.0 with new define TABLE_SCAN_SETUP_COST. - Some scan cost estimates did not take into account TIME_FOR_COMPARE. Now all scan costs takes this into account. (main.show_explain) - Added session variable optimizer_cache_hit_ratio (default 50%). By adjusting this on can reduce or increase the cost of index or direct record lookups. The effect of the default is that key lookups is now a bit cheaper than before. See usage of 'optimizer_cache_cost' in handler.h. - JOIN_TAB::scan_time() did not take into account index only scans, which produced a wrong cost when index scan was used. Changed JOIN_TAB:::scan_time() to take into consideration clustered and covered keys. The values are now cached and we only have to call this function once. Other calls are changed to use the cached values. Function renamed to JOIN_TAB::estimate_scan_time(). - Fixed that most index cost calculations are done the same way and more close to 'range' calculations. The cost is now lower than before for small data sets and higher for large data sets as we take into account how many keys are read (main.opt_trace_selectivity, main.limit_rows_examined). - Ensured that index_scan_cost() == range(scan_of_all_rows_in_table_using_one_range) + MULTI_RANGE_READ_INFO_CONST. One effect of this is that if there is choice of doing a full index scan and a range-index scan over almost the whole table then index scan will be preferred (no range-read setup cost). (innodb.innodb, main.show_explain, main.range) - Fixed the EQ_REF and REF takes into account clustered and covered keys. This changes some plans to use covered or clustered indexes as these are much cheaper. (main.subselect_mat_cost, main.state_tables_innodb, main.limit_rows_examined) - Rowid filter setup cost and filter compare cost now takes into account fetching and checking the rowid (KEY_NEXT_FIND_COST). (main.partition_pruning heap.heap_btree main.log_state) - Added KEY_NEXT_FIND_COST to Range_rowid_filter_cost_info::lookup_cost to account of the time to find and check the next key value against the container - Introduced ha_keyread_time(rows) that takes into account finding the next row and copying the key value to 'record' (KEY_COPY_COST). - Introduced ha_key_scan_time() for calculating an index scan over all rows. - Added IDX_LOOKUP_COST to keyread_time() as a startup cost. - Added index_only_fetch_cost() as a convenience function to OPT_RANGE. - keyread_time() cost is slightly reduced to prefer shorter keys. (main.index_merge_myisam) - All of the above caused some index_merge combinations to be rejected because of cost (main.index_intersect). In some cases 'ref' where replaced with index_merge because of the low cost calculation of get_sweep_read_cost(). - Some index usage moved from PRIMARY to a covering index. (main.subselect_innodb) - Changed cost calculation of filter to take KEY_LOOKUP_COST and TIME_FOR_COMPARE into account. See sql_select.cc::apply_filter(). filter parameters and costs are now written to optimizer_trace. - Don't use matchings_records_in_range() to try to estimate the number of filtered rows for ranges. The reason is that we want to ensure that 'range' is calculated similar to 'ref'. There is also more work needed to calculate the selectivity when using ranges and ranges and filtering. This causes filtering column in EXPLAIN EXTENDED to be 100.00 for some cases where range cannot use filtering. (main.rowid_filter) - Introduced ha_scan_time() that takes into account the CPU cost of finding the next row and copying the row from the engine to 'record'. This causes costs of table scan to slightly increase and some test to changed their plan from ALL to RANGE or ALL to ref. (innodb.innodb_mysql, main.select_pkeycache) In a few cases where scan time of very small tables have lower cost than a ref or range, things changed from ref/range to ALL. (main.myisam, main.func_group, main.limit_rows_examined, main.subselect2) - Introduced ha_scan_and_compare_time() which is like ha_scan_time() but also adds the cost of the where clause (TIME_FOR_COMPARE). - Added small cost for creating temporary table for materialization. This causes some very small tables to use scan instead of materialization. - Added checking of the WHERE clause (TIME_FOR_COMPARE) of the accepted rows to ROR costs in get_best_ror_intersect() - Removed '- 0.001' from 'join->best_read' and optimize_straight_join() to ensure that the 'Last_query_cost' status variable contains the same value as the one that was calculated by the optimizer. - Take avg_io_cost() into account in handler::keyread_time() and handler::read_time(). This should have no effect as it's 1.0 by default, except for heap that overrides these functions. - Some 'ref_or_null' accesses changed to 'range' because of cost adjustments (main.order_by) - Added scan type "scan_with_join_cache" for optimizer_trace. This is just to show in the trace what kind of scan was used. - When using 'scan_with_join_cache' take into account number of preceding tables (as have to restore all fields for all previous table combination when checking the where clause) The new cost added is: (row_combinations * ROW_COPY_COST * number_of_cached_tables). This increases the cost of join buffering in proportion of the number of tables in the join buffer. One effect is that full scans are now done earlier as the cost is then smaller. (main.join_outer_innodb, main.greedy_optimizer) - Removed the usage of 'worst_seeks' in cost_for_index_read as it caused wrong plans to be created; It prefered JT_EQ_REF even if it would be much more expensive than a full table scan. A related issue was that worst_seeks only applied to full lookup, not to clustered or index only lookups, which is not consistent. This caused some plans to use index scan instead of eq_ref (main.union) - Changed federated block size from 4096 to 1500, which is the typical size of an IO packet. - Added costs for reading rows to Federated. Needed as there is no caching of rows in the federated engine. - Added ha_innobase::rnd_pos_time() cost function. - A lot of extra things added to optimizer trace - More costs, especially for materialization and index_merge. - Make lables more uniform - Fixed a lot of minor bugs - Added 'trace_started()' around a lot of trace blocks. - When calculating ORDER BY with LIMIT cost for using an index the cost did not take into account the number of row retrivals that has to be done or the cost of comparing the rows with the WHERE clause. The cost calculated would be just a fraction of the real cost. Now we calculate the cost as we do for ranges and 'ref'. - 'Using index for group-by' is used a bit more than before as now take into account the WHERE clause cost when comparing with 'ref' and prefer the method with fewer row combinations. (main.group_min_max). Bugs fixed: - Fixed that we don't calculate TIME_FOR_COMPARE twice for some plans, like in optimize_straight_join() and greedy_search() - Fixed bug in save_explain_data where we could test for the wrong index when displaying 'Using index'. This caused some old plans to show 'Using index'. (main.subselect_innodb, main.subselect2) - Fixed bug in get_best_ror_intersect() where 'min_cost' was not updated, and the cost we compared with was not the one that was used. - Fixed very wrong cost calculation for priority queues in check_if_pq_applicable(). (main.order_by now correctly uses priority queue) - When calculating cost of EQ_REF or REF, we added the cost of comparing the WHERE clause with the found rows, not all row combinations. This made ref and eq_ref to be regarded way to cheap compared to other access methods. - FORCE INDEX cost calculation didn't take into account clustered or covered indexes. - JT_EQ_REF cost was estimated as avg_io_cost(), which is half the cost of a JT_REF key. This may be true for InnoDB primary key, but not for other unique keys or other engines. Now we use handler function to calculate the cost, which allows us to handle consistently clustered, covered keys and not covered keys. - ha_start_keyread() didn't call extra_opt() if keyread was already enabled but still changed the 'keyread' variable (which is wrong). Fixed by not doing anything if keyread is already enabled. - multi_range_read_info_cost() didn't take into account io_cost when calculating the cost of ranges. - fix_semijoin_strategies_for_picked_join_order() used the wrong record_count when calling best_access_path() for SJ_OPT_FIRST_MATCH and SJ_OPT_LOOSE_SCAN. - Hash joins didn't provide correct best_cost to the upper level, which means that the cost for hash_joins more expensive than calculated in best_access_path (a difference of 10x * TIME_OF_COMPARE). This is fixed in the new code thanks to that we now include TIME_OF_COMPARE cost in 'read_time'. Other things: - Added some 'if (thd->trace_started())' to speed up code - Removed not used function Cost_estimate::is_zero() - Simplified testing of HA_POS_ERROR in get_best_ror_intersect(). (No cost changes) - Moved ha_start_keyread() from join_read_const_table() to join_read_const() to enable keyread for all types of JT_CONST tables. - Made a few very short functions inline in handler.h Notes: - In main.rowid_filter the join order of order and lineitem is swapped. This is because the cost of doing a range fetch of lineitem(98 rows) is almost as big as the whole join of order,lineitem. The filtering will also ensure that we only have to do very small key fetches of the rows in lineitem. - main.index_merge_myisam had a few changes where we are now using less keys for index_merge. This is because index scans are now more expensive than before. - handler->optimizer_cache_cost is updated in ha_external_lock(). This ensures that it is up to date per statements. Not an optimal solution (for locked tables), but should be ok for now. - 'DELETE FROM t1 WHERE t1.a > 0 ORDER BY t1.a' does not take cost of filesort into consideration when table scan is chosen. (main.myisam_explain_non_select_all) - perfschema.table_aggregate_global_* has changed because an update on a table with 1 row will now use table scan instead of key lookup. TODO in upcomming commits: - Fix selectivity calculation for ranges with and without filtering and when there is a ref access but scan is chosen. For this we have to store the lowest known value for 'accepted_records' in the OPT_RANGE structure. - Change that records_read does not include filtered rows. - test_if_cheaper_ordering() needs to be updated to properly calculate costs. This will fix tests like main.order_by_innodb, main.single_delete_update - Extend get_range_limit_read_cost() to take into considering cost_for_index_read() if there where no quick keys. This will reduce the computed cost for ORDER BY with LIMIT in some cases. (main.innodb_ext_key) - Fix that we take into account selectivity when counting the number of rows we have to read when considering using a index table scan to resolve ORDER BY. - Add new calculation for rnd_pos_time() where we take into account the benefit of reading multiple rows from the same page.
2021-11-01 11:34:24 +01:00
# InnoDB sometimes returns 4 other times 5 records for t1
--replace_column 9 #
MDEV-10466 Server crashed in SEL_ARG::store_min() with extended_keys=on This bug could manifest itself in a very rare cases when the optimizer chose an execution plan by which a joined table was accessed by a table scan and the optimizer was checking whether ranges checked for each record could improve this plan. In such cases the optimizer evaluates range conditions over a table that depend on other tables. For such conditions the constructed SEL_ARG trees are marked as MAYBE_KEY. If a SEL_ARG object constructed for a sargable condition marked as RANGE_KEY had the same first key part as a MAYBE_KEY SEL_ARG object and the key_and() function was called for this pair of SEL_ARG objects then an invalid SEL_ARG object could be constructed that ultimately could lead to a crash before the execution phase.
2020-03-15 03:58:57 +01:00
explain
select pk, a, b from t1,t2,t3 where b >= d and pk < c and b = '0';
select pk, a, b from t1,t2,t3 where b >= d and pk < c and b = '0';
set optimizer_switch=@save_optimizer_switch;
drop table t1,t2,t3;
Merge 5.5 into 10.1
2020-04-01 09:24:36 +02:00
MDEV-6453: Assertion `inited==NONE || (inited==RND && scan)' failed in handler::ha_rnd_init(bool) with InnoDB, joins, AND/OR conditions The inited parameter handler is not initialised when we do a quick_select after a table scan.
2018-12-16 20:50:49 +01:00
CREATE TABLE t1 (
pk INT PRIMARY KEY, f1 INT, f2 CHAR(1), f3 CHAR(1),
KEY(f1), KEY(f2)
) ENGINE=InnoDB;
INSERT INTO t1 VALUES
(1,4,'v',NULL),(2,6,'v',NULL),(3,7,'c',NULL),(4,1,'e',NULL),(5,0,'x',NULL),
(6,7,'i',NULL),(7,7,'e',NULL),(8,1,'p',NULL),(9,7,'s',NULL),(10,1,'j',NULL),
(11,5,'z',NULL),(12,2,'c',NULL),(13,0,'a',NULL),(14,1,'q',NULL),(15,8,'y',NULL),
(16,1,'m',NULL),(17,1,'r',NULL),(18,9,'v',NULL),(19,1,'n',NULL);
CREATE TABLE t2 (f4 INT, f5 CHAR(1)) ENGINE=InnoDB;
INSERT INTO t2 VALUES (4,'q'),(NULL,'j');
SELECT * FROM t1 AS t1_1, t1 AS t1_2, t2
WHERE f5 = t1_2.f2 AND ( t1_1.f1 = 103 AND t1_1.f2 = 'o' OR t1_1.pk < f4 );
drop table t1,t2;
MDEV-14440: Assertion `inited==RND' failed in handler::ha_rnd_end In the function QUICK_RANGE_SELECT::init_ror_merged_scan we create a seperate handler if the handler in head->file cannot be reused. The flag free_file tells us if we have a seperate handler or not. There are cases where you might create a handler and then there might be a failure(running ALTER) and then we have to revert the handler back to the original one. The code does that but it does not reset the flag 'free_file' in this case. Also backported f2c418079def.
2019-01-17 21:56:12 +01:00
--echo #
--echo # MDEV-14440: Server crash in in handler::ha_external_lock or Assertion `inited==RND'
--echo # failed in handler::ha_rnd_end upon SELECT from partitioned table
--echo #
Update row and key fetch cost models to take into account data copy costs Before this patch, when calculating the cost of fetching and using a row/key from the engine, we took into account the cost of finding a row or key from the engine, but did not consistently take into account index only accessed, clustered key or covered keys for all access paths. The cost of the WHERE clause (TIME_FOR_COMPARE) was not consistently considered in best_access_path(). TIME_FOR_COMPARE was used in calculation in other places, like greedy_search(), but was in some cases (like scans) done an a different number of rows than was accessed. The cost calculation of row and index scans didn't take into account the number of rows that where accessed, only the number of accepted rows. When using a filter, the cost of index_only_reads and cost of accessing and disregarding 'filtered rows' where not taken into account, which made filters cost less than there actually where. To remedy the above, the following key & row fetch related costs has been added: - The cost of fetching and using a row is now split into different costs: - key + Row fetch cost (as before) but multiplied with the variable 'optimizer_cache_cost' (default to 0.5). This allows the user to tell the optimizer the likehood of finding the key and row in the engine cache. - ROW_COPY_COST, The cost copying a row from the engine to the sql layer or creating a row from the join_cache to the record buffer. Mostly affects table scan costs. - ROW_LOOKUP_COST, the cost of fetching a row by rowid. - KEY_COPY_COST the cost of finding the next key and copying it from the engine to the SQL layer. This is used when we calculate the cost index only reads. It makes index scans more expensive than before if they cover a lot of rows. (main.index_merge_myisam) - KEY_LOOKUP_COST, the cost of finding the first key in a range. This replaces the old define IDX_LOOKUP_COST, but with a higher cost. - KEY_NEXT_FIND_COST, the cost of finding the next key (and rowid). when doing a index scan and comparing the rowid to the filter. Before this cost was assumed to be 0. All of the above constants/variables are now tuned to be somewhat in proportion of executing complexity to each other. There is tuning need for these in the future, but that can wait until the above are made user variables as that will make tuning much easier. To make the usage of the above easy, there are new (not virtual) cost calclation functions in handler: - ha_read_time(), like read_time(), but take optimizer_cache_cost into account. - ha_read_and_copy_time(), like ha_read_time() but take into account ROW_COPY_TIME - ha_read_and_compare_time(), like ha_read_and_copy_time() but take TIME_FOR_COMPARE into account. - ha_rnd_pos_time(). Read row with row id, taking ROW_COPY_COST into account. This is used with filesort where we don't need to execute the WHERE clause again. - ha_keyread_time(), like keyread_time() but take optimizer_cache_cost into account. - ha_keyread_and_copy_time(), like ha_keyread_time(), but add KEY_COPY_COST. - ha_key_scan_time(), like key_scan_time() but take optimizer_cache_cost nto account. - ha_key_scan_and_compare_time(), like ha_key_scan_time(), but add KEY_COPY_COST & TIME_FOR_COMPARE. I also added some setup costs for doing different types of scans and creating temporary tables (on disk and in memory). This encourages the optimizer to not use these for simple 'a few row' lookups if there are adequate key lookup strategies. - TABLE_SCAN_SETUP_COST, cost of starting a table scan. - INDEX_SCAN_SETUP_COST, cost of starting an index scan. - HEAP_TEMPTABLE_CREATE_COST, cost of creating in memory temporary table. - DISK_TEMPTABLE_CREATE_COST, cost of creating an on disk temporary table. When calculating cost of fetching ranges, we had a cost of IDX_LOOKUP_COST (0.125) for doing a key div for a new range. This is now replaced with 'io_cost * KEY_LOOKUP_COST (1.0) * optimizer_cache_cost', which matches the cost we use for 'ref' and other key lookups. The effect is that the cost is now a bit higher when we have many ranges for a key. Allmost all calculation with TIME_FOR_COMPARE is now done in best_access_path(). 'JOIN::read_time' now includes the full cost for finding the rows in the table. In the result files, many of the changes are now again close to what they where before the "Update cost for hash and cached joins" commit, as that commit didn't fix the filter cost (too complex to do everything in one commit). The above changes showed a lot of a lot of inconsistencies in optimizer cost calculation. The main objective with the other changes was to do calculation as similar (and accurate) as possible and to make different plans more comparable. Detailed list of changes: - Calculate index_only_cost consistently and correctly for all scan and ref accesses. The row fetch_cost and index_only_cost now takes into account clustered keys, covered keys and index only accesses. - cost_for_index_read now returns both full cost and index_only_cost - Fixed cost calculation of get_sweep_read_cost() to match other similar costs. This is bases on the assumption that data is more often stored on SSD than a hard disk. - Replaced constant 2.0 with new define TABLE_SCAN_SETUP_COST. - Some scan cost estimates did not take into account TIME_FOR_COMPARE. Now all scan costs takes this into account. (main.show_explain) - Added session variable optimizer_cache_hit_ratio (default 50%). By adjusting this on can reduce or increase the cost of index or direct record lookups. The effect of the default is that key lookups is now a bit cheaper than before. See usage of 'optimizer_cache_cost' in handler.h. - JOIN_TAB::scan_time() did not take into account index only scans, which produced a wrong cost when index scan was used. Changed JOIN_TAB:::scan_time() to take into consideration clustered and covered keys. The values are now cached and we only have to call this function once. Other calls are changed to use the cached values. Function renamed to JOIN_TAB::estimate_scan_time(). - Fixed that most index cost calculations are done the same way and more close to 'range' calculations. The cost is now lower than before for small data sets and higher for large data sets as we take into account how many keys are read (main.opt_trace_selectivity, main.limit_rows_examined). - Ensured that index_scan_cost() == range(scan_of_all_rows_in_table_using_one_range) + MULTI_RANGE_READ_INFO_CONST. One effect of this is that if there is choice of doing a full index scan and a range-index scan over almost the whole table then index scan will be preferred (no range-read setup cost). (innodb.innodb, main.show_explain, main.range) - Fixed the EQ_REF and REF takes into account clustered and covered keys. This changes some plans to use covered or clustered indexes as these are much cheaper. (main.subselect_mat_cost, main.state_tables_innodb, main.limit_rows_examined) - Rowid filter setup cost and filter compare cost now takes into account fetching and checking the rowid (KEY_NEXT_FIND_COST). (main.partition_pruning heap.heap_btree main.log_state) - Added KEY_NEXT_FIND_COST to Range_rowid_filter_cost_info::lookup_cost to account of the time to find and check the next key value against the container - Introduced ha_keyread_time(rows) that takes into account finding the next row and copying the key value to 'record' (KEY_COPY_COST). - Introduced ha_key_scan_time() for calculating an index scan over all rows. - Added IDX_LOOKUP_COST to keyread_time() as a startup cost. - Added index_only_fetch_cost() as a convenience function to OPT_RANGE. - keyread_time() cost is slightly reduced to prefer shorter keys. (main.index_merge_myisam) - All of the above caused some index_merge combinations to be rejected because of cost (main.index_intersect). In some cases 'ref' where replaced with index_merge because of the low cost calculation of get_sweep_read_cost(). - Some index usage moved from PRIMARY to a covering index. (main.subselect_innodb) - Changed cost calculation of filter to take KEY_LOOKUP_COST and TIME_FOR_COMPARE into account. See sql_select.cc::apply_filter(). filter parameters and costs are now written to optimizer_trace. - Don't use matchings_records_in_range() to try to estimate the number of filtered rows for ranges. The reason is that we want to ensure that 'range' is calculated similar to 'ref'. There is also more work needed to calculate the selectivity when using ranges and ranges and filtering. This causes filtering column in EXPLAIN EXTENDED to be 100.00 for some cases where range cannot use filtering. (main.rowid_filter) - Introduced ha_scan_time() that takes into account the CPU cost of finding the next row and copying the row from the engine to 'record'. This causes costs of table scan to slightly increase and some test to changed their plan from ALL to RANGE or ALL to ref. (innodb.innodb_mysql, main.select_pkeycache) In a few cases where scan time of very small tables have lower cost than a ref or range, things changed from ref/range to ALL. (main.myisam, main.func_group, main.limit_rows_examined, main.subselect2) - Introduced ha_scan_and_compare_time() which is like ha_scan_time() but also adds the cost of the where clause (TIME_FOR_COMPARE). - Added small cost for creating temporary table for materialization. This causes some very small tables to use scan instead of materialization. - Added checking of the WHERE clause (TIME_FOR_COMPARE) of the accepted rows to ROR costs in get_best_ror_intersect() - Removed '- 0.001' from 'join->best_read' and optimize_straight_join() to ensure that the 'Last_query_cost' status variable contains the same value as the one that was calculated by the optimizer. - Take avg_io_cost() into account in handler::keyread_time() and handler::read_time(). This should have no effect as it's 1.0 by default, except for heap that overrides these functions. - Some 'ref_or_null' accesses changed to 'range' because of cost adjustments (main.order_by) - Added scan type "scan_with_join_cache" for optimizer_trace. This is just to show in the trace what kind of scan was used. - When using 'scan_with_join_cache' take into account number of preceding tables (as have to restore all fields for all previous table combination when checking the where clause) The new cost added is: (row_combinations * ROW_COPY_COST * number_of_cached_tables). This increases the cost of join buffering in proportion of the number of tables in the join buffer. One effect is that full scans are now done earlier as the cost is then smaller. (main.join_outer_innodb, main.greedy_optimizer) - Removed the usage of 'worst_seeks' in cost_for_index_read as it caused wrong plans to be created; It prefered JT_EQ_REF even if it would be much more expensive than a full table scan. A related issue was that worst_seeks only applied to full lookup, not to clustered or index only lookups, which is not consistent. This caused some plans to use index scan instead of eq_ref (main.union) - Changed federated block size from 4096 to 1500, which is the typical size of an IO packet. - Added costs for reading rows to Federated. Needed as there is no caching of rows in the federated engine. - Added ha_innobase::rnd_pos_time() cost function. - A lot of extra things added to optimizer trace - More costs, especially for materialization and index_merge. - Make lables more uniform - Fixed a lot of minor bugs - Added 'trace_started()' around a lot of trace blocks. - When calculating ORDER BY with LIMIT cost for using an index the cost did not take into account the number of row retrivals that has to be done or the cost of comparing the rows with the WHERE clause. The cost calculated would be just a fraction of the real cost. Now we calculate the cost as we do for ranges and 'ref'. - 'Using index for group-by' is used a bit more than before as now take into account the WHERE clause cost when comparing with 'ref' and prefer the method with fewer row combinations. (main.group_min_max). Bugs fixed: - Fixed that we don't calculate TIME_FOR_COMPARE twice for some plans, like in optimize_straight_join() and greedy_search() - Fixed bug in save_explain_data where we could test for the wrong index when displaying 'Using index'. This caused some old plans to show 'Using index'. (main.subselect_innodb, main.subselect2) - Fixed bug in get_best_ror_intersect() where 'min_cost' was not updated, and the cost we compared with was not the one that was used. - Fixed very wrong cost calculation for priority queues in check_if_pq_applicable(). (main.order_by now correctly uses priority queue) - When calculating cost of EQ_REF or REF, we added the cost of comparing the WHERE clause with the found rows, not all row combinations. This made ref and eq_ref to be regarded way to cheap compared to other access methods. - FORCE INDEX cost calculation didn't take into account clustered or covered indexes. - JT_EQ_REF cost was estimated as avg_io_cost(), which is half the cost of a JT_REF key. This may be true for InnoDB primary key, but not for other unique keys or other engines. Now we use handler function to calculate the cost, which allows us to handle consistently clustered, covered keys and not covered keys. - ha_start_keyread() didn't call extra_opt() if keyread was already enabled but still changed the 'keyread' variable (which is wrong). Fixed by not doing anything if keyread is already enabled. - multi_range_read_info_cost() didn't take into account io_cost when calculating the cost of ranges. - fix_semijoin_strategies_for_picked_join_order() used the wrong record_count when calling best_access_path() for SJ_OPT_FIRST_MATCH and SJ_OPT_LOOSE_SCAN. - Hash joins didn't provide correct best_cost to the upper level, which means that the cost for hash_joins more expensive than calculated in best_access_path (a difference of 10x * TIME_OF_COMPARE). This is fixed in the new code thanks to that we now include TIME_OF_COMPARE cost in 'read_time'. Other things: - Added some 'if (thd->trace_started())' to speed up code - Removed not used function Cost_estimate::is_zero() - Simplified testing of HA_POS_ERROR in get_best_ror_intersect(). (No cost changes) - Moved ha_start_keyread() from join_read_const_table() to join_read_const() to enable keyread for all types of JT_CONST tables. - Made a few very short functions inline in handler.h Notes: - In main.rowid_filter the join order of order and lineitem is swapped. This is because the cost of doing a range fetch of lineitem(98 rows) is almost as big as the whole join of order,lineitem. The filtering will also ensure that we only have to do very small key fetches of the rows in lineitem. - main.index_merge_myisam had a few changes where we are now using less keys for index_merge. This is because index scans are now more expensive than before. - handler->optimizer_cache_cost is updated in ha_external_lock(). This ensures that it is up to date per statements. Not an optimal solution (for locked tables), but should be ok for now. - 'DELETE FROM t1 WHERE t1.a > 0 ORDER BY t1.a' does not take cost of filesort into consideration when table scan is chosen. (main.myisam_explain_non_select_all) - perfschema.table_aggregate_global_* has changed because an update on a table with 1 row will now use table scan instead of key lookup. TODO in upcomming commits: - Fix selectivity calculation for ranges with and without filtering and when there is a ref access but scan is chosen. For this we have to store the lowest known value for 'accepted_records' in the OPT_RANGE structure. - Change that records_read does not include filtered rows. - test_if_cheaper_ordering() needs to be updated to properly calculate costs. This will fix tests like main.order_by_innodb, main.single_delete_update - Extend get_range_limit_read_cost() to take into considering cost_for_index_read() if there where no quick keys. This will reduce the computed cost for ORDER BY with LIMIT in some cases. (main.innodb_ext_key) - Fix that we take into account selectivity when counting the number of rows we have to read when considering using a index table scan to resolve ORDER BY. - Add new calculation for rnd_pos_time() where we take into account the benefit of reading multiple rows from the same page.
2021-11-01 11:34:24 +01:00
call mtr.add_suppression("Got error .* when reading table");
MDEV-14440: Assertion `inited==RND' failed in handler::ha_rnd_end In the function QUICK_RANGE_SELECT::init_ror_merged_scan we create a seperate handler if the handler in head->file cannot be reused. The flag free_file tells us if we have a seperate handler or not. There are cases where you might create a handler and then there might be a failure(running ALTER) and then we have to revert the handler back to the original one. The code does that but it does not reset the flag 'free_file' in this case. Also backported f2c418079def.
2019-01-17 21:56:12 +01:00
set @optimizer_switch_save= @@optimizer_switch;
set optimizer_switch='index_merge_sort_intersection=off';
Work around MDEV-24813 in some tests Not creating explicit record locks will speed up the test. Also, disable the use of InnoDB persistent statistics in the test of MDEV-27270 to avoid intermittent failures in 10.6 or later (after commit 9608773f75e2ca21491ef6825c3616cdc96d1ca5) due to the nondeterministic scheduling of STATS_AUTO_PERSISTENT.
2022-11-08 08:00:58 +01:00
create table t0(a int);
MDEV-14440: Assertion `inited==RND' failed in handler::ha_rnd_end In the function QUICK_RANGE_SELECT::init_ror_merged_scan we create a seperate handler if the handler in head->file cannot be reused. The flag free_file tells us if we have a seperate handler or not. There are cases where you might create a handler and then there might be a failure(running ALTER) and then we have to revert the handler back to the original one. The code does that but it does not reset the flag 'free_file' in this case. Also backported f2c418079def.
2019-01-17 21:56:12 +01:00
insert into t0 values (0),(1),(2),(3),(4),(5),(6),(7),(8),(9);
create table t1 (
a int, b int, c int,
key(a),key(b),key(c)
)engine=innodb;
insert into t1
Work around MDEV-24813 in some tests Not creating explicit record locks will speed up the test. Also, disable the use of InnoDB persistent statistics in the test of MDEV-27270 to avoid intermittent failures in 10.6 or later (after commit 9608773f75e2ca21491ef6825c3616cdc96d1ca5) due to the nondeterministic scheduling of STATS_AUTO_PERSISTENT.
2022-11-08 08:00:58 +01:00
select a.seq/10, a.seq/10, a.seq from seq_0_to_499 a, seq_0_to_4 b;
MDEV-21360 global debug_dbug pre-test value restoration issues
2020-01-09 13:38:48 +01:00
SET @saved_dbug = @@GLOBAL.debug_dbug;
MDEV-14440: Assertion `inited==RND' failed in handler::ha_rnd_end In the function QUICK_RANGE_SELECT::init_ror_merged_scan we create a seperate handler if the handler in head->file cannot be reused. The flag free_file tells us if we have a seperate handler or not. There are cases where you might create a handler and then there might be a failure(running ALTER) and then we have to revert the handler back to the original one. The code does that but it does not reset the flag 'free_file' in this case. Also backported f2c418079def.
2019-01-17 21:56:12 +01:00
set @@global.debug_dbug="+d,ha_index_init_fail";
explain select * from t1 where a=10 and b=10;
--error ER_TABLE_DEF_CHANGED
select * from t1 where a=10 and b=10;
DROP TABLE t0,t1;
MDEV-21360 global debug_dbug pre-test value restoration issues
2020-01-09 13:38:48 +01:00
SET @@GLOBAL.debug_dbug = @saved_dbug;
MDEV-14440: Assertion `inited==RND' failed in handler::ha_rnd_end In the function QUICK_RANGE_SELECT::init_ror_merged_scan we create a seperate handler if the handler in head->file cannot be reused. The flag free_file tells us if we have a seperate handler or not. There are cases where you might create a handler and then there might be a failure(running ALTER) and then we have to revert the handler back to the original one. The code does that but it does not reset the flag 'free_file' in this case. Also backported f2c418079def.
2019-01-17 21:56:12 +01:00
set @@optimizer_switch= @optimizer_switch_save;
MDEV-19634: Assertion `0' failed in row_sel_convert_mysql_key_to_innobase, [Warning] InnoDB: Using a partial-field key prefix in search For a key with keyparts (k1,k2,k3) , if we are building a range over the keyparts we should make sure that if min_value/max_value for a keypart is not added to key buffer then the keyparts following should also not be allowed.
2019-06-14 08:46:17 +02:00
Merge 5.5 into 10.1
2020-04-01 09:24:36 +02:00
--echo # End of 10.1 tests
Merge 10.3 into 10.4 In main.index_merge_myisam we remove the test that was added in commit a2d24def8cc42d27c72d833abfb39ef24a2b96ba because it duplicates the test case that was added in commit 5af12e463549e4bbc2ce6ab720d78937d5e5db4e.
2020-04-16 11:12:26 +02:00
MDEV-27262 Unexpected index intersection with full index scan for an index If when extracting a range condition for an index from the WHERE condition Range Optimizer sees that the range condition covers the whole index then such condition should be discarded because it cannot be used in any range scan. In some cases Range Optimizer really does it, but there remained some conditions for which it was not done. As a result the optimizer could produce index merge plans with the full index scan for one of the indexes participating in the index merge. This could be observed in one of the test cases from index_merge1.inc where a plan with index_merge_sort_union was produced and in the test case reported for this bug where a plan with index_merge_sort_intersect was produced. In both cases one of two index scans participating in index merge ran over the whole index. The patch slightly changes the original above mentioned test case from index_merge1.inc to be able to produce an intended plan employing index_merge_sort_union. The original query was left to show that index merge is not used for it anymore. It should be noted that for the plan with index_merge_sort_intersect could be chosen for execution only due to a defect in the InnoDB code that returns wrong estimates for the cardinality of big ranges. This bug led to serious problems in 10.4+ where the optimization using Rowid filters is employed (see mdev-26446). Approved by Sergey Petrunia <sergey@mariadb.com>
2021-12-21 04:55:00 +01:00
--echo #
--echo # MDEV-27262: Index intersection with full scan over an index
--echo #
CREATE TABLE t1 (
id int(10) unsigned NOT NULL AUTO_INCREMENT,
p char(32) DEFAULT NULL,
es tinyint(3) unsigned NOT NULL DEFAULT 0,
er tinyint(3) unsigned NOT NULL DEFAULT 0,
x mediumint(8) unsigned NOT NULL DEFAULT 0,
PRIMARY KEY (id),
INDEX es (es),
INDEX x (x),
INDEX er (er,x),
INDEX p (p)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
insert into t1(es,er) select 0, 1 from seq_1_to_45;
insert into t1(es,er) select 0, 2 from seq_1_to_49;
insert into t1(es,er) select 0, 3 from seq_1_to_951;
insert into t1(es,er) select 0, 3 from seq_1_to_1054;
insert into t1(es,er) select 0, 6 from seq_1_to_25;
insert into t1(es,er) select 0, 11 from seq_1_to_1;
insert into t1(es,er) select 1, 1 from seq_1_to_45;
insert into t1(es,er) select 1, 2 from seq_1_to_16;
insert into t1(es,er) select 1, 3 from seq_1_to_511;
insert into t1(es,er) select 1, 4 from seq_1_to_687;
insert into t1(es,er) select 1, 6 from seq_1_to_50;
insert into t1(es,er) select 1, 7 from seq_1_to_4;
insert into t1(es,er) select 1, 11 from seq_1_to_1;
insert into t1(es,er) select 2, 1 from seq_1_to_82;
insert into t1(es,er) select 2, 2 from seq_1_to_82;
insert into t1(es,er) select 2, 3 from seq_1_to_1626;
insert into t1(es,er) select 2, 4 from seq_1_to_977;
insert into t1(es,er) select 2, 6 from seq_1_to_33;
insert into t1(es,er) select 2, 11 from seq_1_to_1;
insert into t1(es,er) select 3, 1 from seq_1_to_245;
insert into t1(es,er) select 3, 2 from seq_1_to_81;
insert into t1(es,er) select 3, 3 from seq_1_to_852;
insert into t1(es,er) select 3, 4 from seq_1_to_2243;
insert into t1(es,er) select 3, 6 from seq_1_to_44;
insert into t1(es,er) select 3, 11 from seq_1_to_1;
insert into t1(es,er) select 4, 1 from seq_1_to_91;
insert into t1(es,er) select 4, 2 from seq_1_to_83;
insert into t1(es,er) select 4, 3 from seq_1_to_297;
insert into t1(es,er) select 4, 4 from seq_1_to_2456;
insert into t1(es,er) select 4, 6 from seq_1_to_19;
insert into t1(es,er) select 4, 11 from seq_1_to_1;
update t1 set p='foobar';
update t1 set x=0;
set @save_isp=@@innodb_stats_persistent;
set global innodb_stats_persistent= 1;
analyze table t1;
let $q=
SELECT * FROM t1
WHERE ((p = 'foo' AND er != 4) OR er = 4 ) AND (es >= 4) LIMIT 2;
set optimizer_switch='index_merge_sort_intersection=on';
eval $q;
--replace_column 9 #
eval EXPLAIN EXTENDED $q;
set optimizer_switch='index_merge_sort_intersection=off';
# execution of $q and explain for it led to an assertion failure in 10.4
# (with the optimizer switch rowid_filter set to 'on')
eval $q;
--replace_column 9 #
eval EXPLAIN EXTENDED $q;
let $q=
SELECT * FROM t1
WHERE ((p = 'foo' AND er < 6) OR er >=2 ) AND (es >= 4) LIMIT 2;
set optimizer_switch='index_merge_sort_intersection=on';
eval $q;
--replace_column 9 #
eval EXPLAIN EXTENDED $q;
set optimizer_switch='index_merge_sort_intersection=off';
eval $q;
--replace_column 9 #
eval EXPLAIN EXTENDED $q;
set optimizer_switch='index_merge_sort_intersection=default';
set global innodb_stats_persistent= @save_isp;
DROP TABLE t1;
--echo # End of 10.2 tests
Merge branch '10.3' into 10.4
2022-01-30 09:46:52 +01:00
MDEV-19634: Assertion `0' failed in row_sel_convert_mysql_key_to_innobase, [Warning] InnoDB: Using a partial-field key prefix in search For a key with keyparts (k1,k2,k3) , if we are building a range over the keyparts we should make sure that if min_value/max_value for a keypart is not added to key buffer then the keyparts following should also not be allowed.
2019-06-14 08:46:17 +02:00
--echo #
--echo # MDEV-19634: Assertion `0' failed in row_sel_convert_mysql_key_to_innobase,
--echo # [Warning] InnoDB: Using a partial-field key prefix in search
--echo #
CREATE TABLE t1 (
pk INT,
a VARCHAR(1),
b INT,
PRIMARY KEY (pk),
KEY (a,b)
) ENGINE=InnoDB;
INSERT INTO t1 VALUES (1,'a',1),(2,'b',2);
explain SELECT a FROM t1 WHERE pk < 0 AND a <= 'w' and b > 0;
SELECT a FROM t1 WHERE pk < 0 AND a <= 'w' and b > 0;
drop table t1;
Merge 10.3 into 10.4 In main.index_merge_myisam we remove the test that was added in commit a2d24def8cc42d27c72d833abfb39ef24a2b96ba because it duplicates the test case that was added in commit 5af12e463549e4bbc2ce6ab720d78937d5e5db4e.
2020-04-16 11:12:26 +02:00
-- echo # End of 10.4 tests
MDEV-31501 Assertion `cond_selectivity <= 1.000000001' failed (actual value 1.125) The problem was that because there was no good indexes for the lineitem table make_join_select() tried to do a last attempt to find a usable key and called test_quick_select(). test_quick_select() found an index with fewer matching rows then every before and that caused a problem in get_range_limit_read_cost(), which assumes that 'best_rows' is the minium rows matched when all conditions has been taken into account and thus smaller than rows found in the range. Fixed by adjusting best_rows to the least rows in any index after test_quick_select() has been called.
2023-08-08 20:02:23 +02:00
--echo #
--echo # MDEV-31501 Assertion `cond_selectivity <= 1.000000001' failed
--echo # (actual value 1.125)
--echo #
CREATE TABLE lineitem (l_orderkey int(11) NOT NULL DEFAULT '0', l_partkey int(11) DEFAULT NULL, l_suppkey int(11) DEFAULT NULL, l_linenumber int(11) NOT NULL DEFAULT '0', l_quantity double DEFAULT NULL, l_extendedprice double DEFAULT NULL, l_discount double DEFAULT NULL, l_tax double DEFAULT NULL, l_returnflag char(1) DEFAULT NULL, l_linestatus char(1) DEFAULT NULL, l_shipDATE date DEFAULT NULL, l_commitDATE date DEFAULT NULL, l_receiptDATE date DEFAULT NULL, l_shipinstruct char(25) DEFAULT NULL, l_shipmode char(10) DEFAULT NULL, l_comment varchar(44) DEFAULT NULL, PRIMARY KEY (l_orderkey,l_linenumber), KEY i_l_shipdate (l_shipDATE), KEY i_l_suppkey_partkey (l_partkey,l_suppkey), KEY i_l_partkey (l_partkey), KEY i_l_suppkey (l_suppkey), KEY i_l_receiptdate (l_receiptDATE), KEY i_l_orderkey (l_orderkey), KEY i_l_orderkey_quantity (l_orderkey,l_quantity), KEY i_l_commitdate (l_commitDATE)) ENGINE=InnoDB;
CREATE TABLE part (p_partkey int(11) NOT NULL, p_name varchar(55) DEFAULT NULL, p_mfgr char(25) DEFAULT NULL, p_brand char(10) DEFAULT NULL, p_type varchar(25) DEFAULT NULL, p_size int(11) DEFAULT NULL, p_container char(10) DEFAULT NULL, p_retailprice double DEFAULT NULL, p_comment varchar(23) DEFAULT NULL, PRIMARY KEY (p_partkey)) ENGINE=InnoDB;
CREATE TABLE partsupp (ps_partkey int(11) NOT NULL DEFAULT '0', ps_suppkey int(11) NOT NULL DEFAULT '0', ps_availqty int(11) DEFAULT NULL, ps_supplycost double DEFAULT NULL, ps_comment varchar(199) DEFAULT NULL, PRIMARY KEY (ps_partkey,ps_suppkey), KEY i_ps_partkey (ps_partkey), KEY i_ps_suppkey (ps_suppkey)) ENGINE=InnoDB;
INSERT INTO lineitem VALUES (581,7,1,1,41,37187,0.09,0.07,'N','O','1997-05-26','1997-04-06','1997-06-10','TAKE BACK RETURN','MAIL','even, bold excuses about the'),(581,10,1,2,14,12740.14,0.06,0.08,'N','O','1997-05-17','1997-04-14','1997-06-08','NONE','MAIL','furiously silent depths'),(581,11,1,3,49,44639.49,0.1,0.02,'N','O','1997-02-27','1997-04-24','1997-03-10','TAKE BACK RETURN','MAIL','furiously regular theodolites wake qu'),(581,8,1,4,30,27240,0.1,0.08,'N','O','1997-06-19','1997-05-21','1997-06-22','TAKE BACK RETURN','TRUCK','even deposits wa'),(582,6,1,1,7,6342,0.07,0,'N','O','1997-11-16','1997-11-29','1997-12-10','TAKE BACK RETURN','FOB','carefully final requests sleep slyly. even,'),(582,6,1,2,49,44394,0.05,0.03,'N','O','1997-12-17','1998-01-12','1997-12-31','COLLECT COD','REG AIR','carefully regular'),(582,15,1,3,42,38430.42,0.07,0,'N','O','1997-11-15','1997-12-21','1997-12-03','COLLECT COD','SHIP','pending, spe'),(582,17,1,4,36,33012.36,0.06,0.01,'N','O','1997-12-09','1997-11-27','1997-12-26','TAKE BACK RETURN','SHIP','slyly final foxes nag permanen');
INSERT INTO part VALUES (1,'goldenrod lace spring peru powder','Manufacturer#1','Brand#13','PROMO BURNISHED COPPER',7,'JUMBO PKG',901,'final deposits s'),(2,'blush rosy metallic lemon navajo','Manufacturer#1','Brand#13','LARGE BRUSHED BRASS',1,'LG CASE',902,'final platelets hang f'),(3,'dark green antique puff wheat','Manufacturer#4','Brand#42','STANDARD POLISHED BRASS',21,'WRAP CASE',903,'unusual excuses ac'),(4,'chocolate metallic smoke ghost drab','Manufacturer#3','Brand#34','SMALL PLATED BRASS',14,'MED DRUM',904,'ironi'),(5,'forest blush chiffon thistle chocolate','Manufacturer#3','Brand#32','STANDARD POLISHED TIN',15,'SM PKG',905,'pending, spe'),(6,'white ivory azure firebrick black','Manufacturer#2','Brand#24','PROMO PLATED STEEL',4,'MED BAG',906,'pending pinto be'),(7,'blue blanched tan indian olive','Manufacturer#1','Brand#11','SMALL PLATED COPPER',45,'SM BAG',907,'blithely ironic');
INSERT INTO partsupp VALUES (1,1,3325,771.64,'requests after the carefully ironic ideas cajole alongside of the enticingly special accounts. fluffily regular deposits haggle about the blithely ironic deposits. regular requests sleep c'),(2,1,8895,378.49,'furiously even asymptotes are furiously regular plate'),(3,1,4651,920.92,'ironic, pending theodolites sleep slyly at the slyly final foxes. slyly ironic accounts sleep express accounts. quickly fina'),(4,1,1339,113.97,'furiously even accounts sleep. slyly regular deposits hag'),(5,1,3735,255.88,'even, ironic requests snooze blithely throughout the carefully pending deposits. busy deposits mold blithely after the furiously final pinto beans. regular, unus'),(6,1,8851,130.72,'carefully regular asymptotes wake slyly according to the quickly re'),(7,1,7454,763.98,'carefully even ideas should wake. blithely final instructions are special foxes. pending, ironic requests wake blithely about the furiously regular foxes. ironic idea'),(8,1,6834,249.63,'furiously unusual instructions use quickly. unusual deposits among the regular deposits doze unusual epitaph'),(9,1,7054,84.2,'final ideas through the requests boost quickly about the furiously regular accounts. blithely silent foxes affix carefully ironic instructions. blithely bold foxe'),(10,1,2952,996.12,'blithely even foxes nag furiously about the quickly ex'),(11,1,4540,709.87,'final packages mold after the carefully unusual requests. quickly fi'),(12,1,3610,659.73,'unusual dolphins sleep slyly. ironic deposits use fluffily. carefully unusual platelets poach slyly. evenly pending deposits nag ironi'),(13,1,612,169.44,'blithely special theodolites serve quickly. regular deposits are alongside of the fluffily sl'),(14,1,5278,650.07,'quickly even deposits doze quickly pending, bold deposits. carefully regular packages sublate carefully'),(15,1,7047,835.7,'packages haggle across the carefully express ideas. slyly bold instructions promise even, express packages. furiously ironic acc');
SELECT ps_suppkey FROM part
JOIN partsupp ON (p_partkey = ps_partkey)
JOIN lineitem ON (ps_partkey = l_partkey AND ps_suppkey = l_suppkey)
WHERE p_partkey != 222 order by 1 limit 1;
drop table partsupp,part,lineitem;
--echo #
--echo # End of 11.0 tests
--echo #
Reference in a new issue Copy permalink