summaryrefslogtreecommitdiff
path: root/sql/opt_range.cc
Commit message (Collapse)AuthorAgeFilesLines
* Merge 10.4 into 10.5Marko Mäkelä2021-04-141-17/+53
|\
| * MDEV-23634: Select query hanged the server and leads to OOM ...bb-10.4-mdev23634Sergei Petrunia2021-04-081-17/+53
| | | | | | | | | | | | | | | | | | | | Handle "col<>const" in the same way that MDEV-21958 did for "col NOT IN(const-list)": do not use the condition for range/index_merge accesses if there is a unique UNIQUE KEY(col). The testcase is in main/range.test. The rest of test updates are due to widespread use of 'pk<>1' in the testsuite. Changed the test to use different but equivalent forms of the conditions.
* | MDEV-25069: Assertion `root->weight >= ...' failed in SEL_ARG::tree_delete #2Sergei Petrunia2021-03-171-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | Note they key_or() may call tree_delete(), which will cause the weight asserts to be checked. In order to avoid them from firing, update key1 tree's weight after we've changed key1->some_local_child->next_key_part. Having done that, do we still need this at the function end: /* Re-compute the result tree's weight. */ key1->update_weight_locally(); ?
* | MDEV-24953: 10.5.9 crashes with large IN() listSergei Petrunia2021-02-241-17/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The problem was in and_all_keys(), the code of MDEV-9759 which calculates the new tree weight: First, it didn't take into account the case when (next->next_key_part=tmp) == NULL and dereferenced a NULL pointer when getting tmp->weight. Second, "if (param->alloced_sel_args > SEL_ARG::MAX_SEL_ARGS) break" could leave the loop with incorrect value of weight. Fixed by introducing SEL_ARG::update_weight_locally() and calling it at the end of the function. This allows to avoid caring about all the above cases.
* | Merge branch 'bb-10.4-release' into bb-10.5-releaseSergei Golubchik2021-02-151-23/+22
|\ \ | |/
| * Merge branch 'bb-10.3-release' into bb-10.4-releaseSergei Golubchik2021-02-121-23/+22
| |\ | | | | | | | | | | | | Note, the fix for "MDEV-23328 Server hang due to Galera lock conflict resolution" was null-merged. 10.4 version of the fix is coming up separately
| | * Merge branch '10.2' into 10.3Sergei Golubchik2021-02-011-0/+1
| | |\
| | | * MDEV-22251: get_key_scans_params: Conditional jump or move depends on ↵Sergei Petrunia2021-01-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | uninitialised value Apply the patch based on the patch by Varun Gupta: PARAM::is_ror_scan might be used unitialized when check_quick_select() is invoked for a "degenerate" SEL_ARG tree (e.g. one having type SEL_ARG::IMPOSSIBLE). Make check_quick_select() always initialize PARAM::is_ror_scan.
| | | * MDEV-17556 Assertion `bitmap_is_set_all(&table->s->all_set)' failedNikita Malyavin2021-01-081-17/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The assertion failed in handler::ha_reset upon SELECT under READ UNCOMMITTED from table with index on virtual column. This was the debug-only failure, though the problem is mush wider: * MY_BITMAP is a structure containing my_bitmap_map, the latter is a raw bitmap. * read_set, write_set and vcol_set of TABLE are the pointers to MY_BITMAP * The rest of MY_BITMAPs are stored in TABLE and TABLE_SHARE * The pointers to the stored MY_BITMAPs, like orig_read_set etc, and sometimes all_set and tmp_set, are assigned to the pointers. * Sometimes tmp_use_all_columns is used to substitute the raw bitmap directly with all_set.bitmap * Sometimes even bitmaps are directly modified, like in TABLE::update_virtual_field(): bitmap_clear_all(&tmp_set) is called. The last three bullets in the list, when used together (which is mostly always) make the program flow cumbersome and impossible to follow, notwithstanding the errors they cause, like this MDEV-17556, where tmp_set pointer was assigned to read_set, write_set and vcol_set, then its bitmap was substituted with all_set.bitmap by dbug_tmp_use_all_columns() call, and then bitmap_clear_all(&tmp_set) was applied to all this. To untangle this knot, the rule should be applied: * Never substitute bitmaps! This patch is about this. orig_*, all_set bitmaps are never substituted already. This patch changes the following function prototypes: * tmp_use_all_columns, dbug_tmp_use_all_columns to accept MY_BITMAP** and to return MY_BITMAP * instead of my_bitmap_map* * tmp_restore_column_map, dbug_tmp_restore_column_maps to accept MY_BITMAP* instead of my_bitmap_map* These functions now will substitute read_set/write_set/vcol_set directly, and won't touch underlying bitmaps.
| | * | MDEV-17556 Assertion `bitmap_is_set_all(&table->s->all_set)' failedNikita Malyavin2021-01-271-17/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The assertion failed in handler::ha_reset upon SELECT under READ UNCOMMITTED from table with index on virtual column. This was the debug-only failure, though the problem is mush wider: * MY_BITMAP is a structure containing my_bitmap_map, the latter is a raw bitmap. * read_set, write_set and vcol_set of TABLE are the pointers to MY_BITMAP * The rest of MY_BITMAPs are stored in TABLE and TABLE_SHARE * The pointers to the stored MY_BITMAPs, like orig_read_set etc, and sometimes all_set and tmp_set, are assigned to the pointers. * Sometimes tmp_use_all_columns is used to substitute the raw bitmap directly with all_set.bitmap * Sometimes even bitmaps are directly modified, like in TABLE::update_virtual_field(): bitmap_clear_all(&tmp_set) is called. The last three bullets in the list, when used together (which is mostly always) make the program flow cumbersome and impossible to follow, notwithstanding the errors they cause, like this MDEV-17556, where tmp_set pointer was assigned to read_set, write_set and vcol_set, then its bitmap was substituted with all_set.bitmap by dbug_tmp_use_all_columns() call, and then bitmap_clear_all(&tmp_set) was applied to all this. To untangle this knot, the rule should be applied: * Never substitute bitmaps! This patch is about this. orig_*, all_set bitmaps are never substituted already. This patch changes the following function prototypes: * tmp_use_all_columns, dbug_tmp_use_all_columns to accept MY_BITMAP** and to return MY_BITMAP * instead of my_bitmap_map* * tmp_restore_column_map, dbug_tmp_restore_column_maps to accept MY_BITMAP* instead of my_bitmap_map* These functions now will substitute read_set/write_set/vcol_set directly, and won't touch underlying bitmaps.
* | | | MDEV-24739: Assertion `root->weight >= ...' failed in SEL_ARG::tree_deleteSergei Petrunia2021-01-301-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Also update the SEL_ARG graph weight in: - sel_add() - SEL_ARG::clone() Make key_{and,or}_with_limit() to also verify weight for the arguments (There is no single point to verify SEL_ARG graphs constructed from conditions that are not AND-OR formulas, so we hope that those are connected with AND/OR and do it here).
* | | | MDEV-9750: Quick memory exhaustion with 'extended_keys=on' ...Sergei Petrunia2021-01-291-6/+296
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (Variant #5, full patch, for 10.5) Do not produce SEL_ARG graphs that would yield huge numbers of ranges. Introduce a concept of SEL_ARG graph's "weight". If we are about to produce a graph whose "weight" exceeds the limit, remove the parts of SEL_ARG graph that represent the biggest key parts. Do so until the graph's is within the limit. Includes - debug code to verify SEL_ARG graph weight - A user-visible @@optimizer_max_sel_arg_weight to control the optimization - Logging the optimization into the optimizer trace.
* | | | Merge commit '10.4' into 10.5Oleksandr Byelkin2021-01-061-0/+24
|\ \ \ \ | |/ / /
| * | | Merge branch '10.3' into 10.4bb-10.4-MDEV-23468Oleksandr Byelkin2020-12-251-2/+2
| |\ \ \ | | |/ /
| | * | Merge branch '10.2' into 10.3Oleksandr Byelkin2020-12-241-1/+1
| | |\ \ | | | |/
| | | * Fix MDEV-21958 code to be working with not 64 MAX_INDEXESOleksandr Byelkin2020-12-241-1/+1
| | | |
| | * | Merge branch '10.2' into 10.3Oleksandr Byelkin2020-12-231-0/+24
| | |\ \ | | | |/
| | | * MDEV-24444: ASAN use-after-poison in Item_func_in::get_func_mm_tree with NOT INSergei Petrunia2020-12-221-1/+1
| | | | | | | | | | | | | | | | | | | | Fix a trivial error in the fix for MDEV-21958: check the key in the right table.
| | | * MDEV-21958: Query having many NOT-IN clauses running foreverSergei Petrunia2020-12-151-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Basic variant of the fix: do not consider conditions in form unique_key NOT IN (c1,c2...) to be sargable. If there are only a few constants, the condition is not selective. If there are a lot constants, the overhead of processing such a huge range list is not worth it. (Backport to 10.2)
| | | * Merge mariadb-10.2.36 into 10.2Marko Mäkelä2020-11-111-7/+7
| | | |\
| | * | \ Merge mariadb-10.3.27 into 10.3Marko Mäkelä2020-11-111-7/+7
| | |\ \ \
| * | | | | MDEV-21958: Query having many NOT-IN clauses running foreverSergei Petrunia2020-12-111-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Basic variant of the fix: do not consider conditions in form unique_key NOT IN (c1,c2...) to be sargable. If there are only a few constants, the condition is not selective. If there are a lot constants, the overhead of processing such a huge range list is not worth it.
| * | | | | Merge mariadb-10.4.17 into 10.4Marko Mäkelä2020-11-111-7/+7
| |\ \ \ \ \
* | \ \ \ \ \ Merge mariadb-10.5.8 into 10.5Marko Mäkelä2020-11-111-7/+7
|\ \ \ \ \ \ \
| * \ \ \ \ \ \ Merge branch '10.4' into 10.5mariadb-10.5.8Sergei Golubchik2020-11-101-7/+7
| |\ \ \ \ \ \ \ | | | |/ / / / / | | |/| | | | |
| | * | | | | | Merge branch '10.3' into 10.4mariadb-10.4.17Sergei Golubchik2020-11-101-7/+7
| | |\ \ \ \ \ \ | | | | |_|/ / / | | | |/| | | |
| | | * | | | | Merge branch '10.2' into 10.3Sergei Golubchik2020-11-091-7/+7
| | | |\ \ \ \ \ | | | | | |_|_|/ | | | | |/| | |
| | | | * | | | MDEV-23811: With large number of indexes optimizer chooses an inefficient planmariadb-10.2.36Igor Babaev2020-11-091-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This bug could manifest itself for a query with WHERE condition containing top level OR formula such that each conjunct contained a single-range condition supported by the same index. One of these range conditions must be fully covered by another range condition that is used later in the OR formula. Additionally at least one of these condition should be ANDed with a sargable range condition supported by a different index. There were several attempts to fix related problems for OR conditions after the backport of range optimizer code from MySQL (commit 0e19f3e36f7842583feb6bead2c2600cd620bced). Unfortunately the first of these fixes contained typo remained unnoticed until recently. This typo bug led to rejection of valid range accesses. This patch fixed this typo bug. The fix revealed another two bugs: one in a constructor for SEL_ARG, the other in the function tree_or(). Both are fixed in this patch.
| | | | * | | | MDEV-24117: Memory management problem in statistics state for ... INSergei Petrunia2020-11-091-12/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Part#1: Revert the patch that caused it: commit 291be494744abe90f4bdf6b5a35c4c26ee8ddda5 Author: Igor Babaev <igor@askmonty.org> Date: Thu Sep 24 22:02:00 2020 -0700 MDEV-23811: With large number of indexes optimizer chooses an inefficient plan
* | | | | | | | Merge 10.4 into 10.5Marko Mäkelä2020-11-031-0/+107
|\ \ \ \ \ \ \ \ | |/ / / / / / / |/| | | | / / / | | |_|_|/ / / | |/| | | | |
| * | | | | | Merge 10.3 into 10.4Marko Mäkelä2020-11-031-0/+107
| |\ \ \ \ \ \ | | |/ / / / / | |/| | | / / | | | |_|/ / | | |/| | |
| | * | | | Merge 10.2 into 10.3Marko Mäkelä2020-11-021-1/+1
| | |\ \ \ \ | | | | |_|/ | | | |/| |
| | | * | | fixup a593e03d58f922a99ba49de1bec6810fc7e9874f: nullptrMarko Mäkelä2020-11-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | C++11 is allowed only starting with MariaDB Server 10.4.
| | * | | | Merge 10.2 into 10.3Marko Mäkelä2020-11-021-0/+107
| | |\ \ \ \ | | | |/ / / | | | | / / | | | |/ / | | |/| |
| | | * | Add dbug_print_sel_arg() debugging help functionSergei Petrunia2020-11-011-0/+107
| | | |/
* | | | Merge 10.4 to 10.5Marko Mäkelä2020-10-221-8/+12
|\ \ \ \ | |/ / /
| * | | Merge 10.3 into 10.4Marko Mäkelä2020-10-221-8/+12
| |\ \ \ | | |/ /
| | * | Merge 10.2 into 10.3Marko Mäkelä2020-10-221-8/+12
| | |\ \ | | | |/
| | | * MDEV-23811: With large number of indexes optimizer chooses an inefficient planIgor Babaev2020-10-061-8/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This bug could manifest itself for a query with WHERE condition containing top level OR formula such that each conjunct contained a single-range condition supported by the same index. One of these range conditions must be fully covered by another range condition that is used later in the OR formula. Additionally at least one of these condition should be ANDed with a sargable range condition supported by a different index. There were several attempts to fix related problems for OR conditions after the backport of range optimizer code from MySQL (commit 0e19f3e36f7842583feb6bead2c2600cd620bced). Unfortunately the first of these fixes contained typo remained unnoticed until recently. This typo bug led to rejection of valid range accesses. This patch fixed this typo bug. The fix revealed another two bugs: one in a constructor for SEL_ARG, the other in the function tree_or(). Both are fixed in this patch.
| * | | Merge 10.3 into 10.4Marko Mäkelä2020-09-031-7/+9
| |\ \ \ | | |/ /
| | * | Merge 10.2 into 10.3Marko Mäkelä2020-09-031-7/+9
| | |\ \ | | | |/
| | | * Fix GCC 10.2.0 -Og -Wmaybe-uninitializedMarko Mäkelä2020-09-011-7/+9
| | | |
| | * | Fixed bugs found by valgrindMonty2020-07-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | - Some of the bug fixes are backports from 10.5! - The fix in innobase/fil/fil0fil.cc is just a backport to get less error messages in mysqld.1.err when running with valgrind. - Renamed HAVE_valgrind_or_MSAN to HAVE_valgrind
* | | | MDEV-22535 TABLE::initialize_quick_structures() takes 0.5% in oltp_read_onlyMonty2020-07-021-32/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed by: - Make all quick_* variable allocated according to real number keys instead of MAX_KEY - Store all the quick* items in separated allocated structure (OPT_RANGE) - Ensure we don't access any quick* variable without first checking opt_range_keys.is_set(). Thanks to this, we don't need any pre-initialization of quick* variables anymore. Some renames was done to use the new structure: table->quick_keys -> table->opt_range_keys table->quick_rows[X] -> table->opt_range[X].rows table->quick_key_parts[X] -> table->opt_range[X].key_parts table->quick_costs[X] -> table->opt_range[X].cost table->quick_index_only_costs[X] -> table->opt_range[X].index_only_cost table->quick_n_ranges[X] -> table->opt_range[X].ranges table->quick_condition_rows -> table->opt_range_condition_rows This patch should both decrease memory needed for TABLE objects (3528 -> 984 + keyinfo) and increase performance, thanks to less initializations per query, and more localized memory, thanks to the opt_range structure.
* | | | Merge 10.4 into 10.5Marko Mäkelä2020-07-021-40/+89
|\ \ \ \ | |/ / /
| * | | MDEV-22910: SIGSEGV in Opt_trace_context::is_started & SIGSEGV in ↵Varun Gupta2020-06-301-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Json_writer::add_table_name (on optimized builds) Make sure to initialize members of TABLE::reginfo when TABLE::init is called. In this case the problem was that table->reginfo.join_tab was set for the SELECT query and then was reused by the UPDATE query. This case occurred only when the SELECT query had a degenerate join.
| * | | MDEV-22665: Print ranges in the optimizer trace created for non-indexed ↵Varun Gupta2020-06-181-36/+87
| | | | | | | | | | | | | | | | | | | | | | | | columns when optimizer_use_condition_selectivity >2 Now the optimizer trace shows the ranges constructed while getting estimates from EITS
* | | | Merge 10.4 into 10.5Marko Mäkelä2020-06-181-9/+0
|\ \ \ \ | |/ / /
| * | | Remove redundant code in opt_range.cc: print_key_value()Sergei Petrunia2020-06-171-9/+0
| | | |
* | | | Merge 10.4 into 10.5Aleksey Midenkov2020-05-151-0/+2
|\ \ \ \ | |/ / /
View Lorry Controller Status