summaryrefslogtreecommitdiff
path: root/sql/item_cmpfunc.h
Commit message (Collapse)AuthorAgeFilesLines
* MDEV-23634: Select query hanged the server and leads to OOM ...bb-10.4-mdev23634Sergei Petrunia2021-04-081-5/+1
| | | | | | | | | | 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.
* Merge branch '10.3' into 10.4bb-10.4-MDEV-23468Oleksandr Byelkin2020-12-251-0/+7
|\
| * Merge branch '10.2' into 10.3Oleksandr Byelkin2020-12-231-0/+7
| |\
| | * Item_func_like::walk() was ignoring escape_itemSergei Golubchik2020-12-191-0/+7
| | | | | | | | | | | | | | | in particular, it caused escape_item->is_expensive() property to be lost instead of being properly propagated up.
* | | Merge 10.3 into 10.4Marko Mäkelä2020-10-291-9/+10
|\ \ \ | |/ /
| * | Merge 10.2 into 10.3Marko Mäkelä2020-10-281-9/+10
| |\ \ | | |/
| | * precedence bugfixingSergei Golubchik2020-10-231-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fix printing precedence for BETWEEN, LIKE/ESCAPE, REGEXP, IN don't use precedence for printing CASE/WHEN/THEN/ELSE/END fix parsing precedence of BETWEEN, LIKE/ESCAPE, REGEXP, IN support predicate arguments for IN, BETWEEN, SOUNDS LIKE, LIKE/ESCAPE, REGEXP use %nonassoc for unary operators fix parsing of IS TRUE/FALSE/UNKNOWN/NULL remove parser_precedence test as superseded by the precedence test
| | * cleanup: remove redundant BANG_PRECEDENCESergei Golubchik2020-10-231-1/+1
| | | | | | | | | | | | | | | prefix unary operators don't need to have different precedence, the syntax unambiguously specifies in what order they apply
* | | Merge branch '10.3' into 10.4Oleksandr Byelkin2020-08-031-1/+1
|\ \ \ | |/ /
| * | Merge branch '10.2' into 10.3Oleksandr Byelkin2020-08-031-1/+1
| |\ \ | | |/
| | * Merge branch '10.1' into 10.2Oleksandr Byelkin2020-08-021-1/+1
| | |\
| | | * Code comment spellfixesIan Gilfillan2020-07-221-1/+1
| | | |
* | | | MDEV-21184 Assertion `used_tables_cache == 0' failed in Item_func::fix_fieldsIgor Babaev2020-01-151-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | with condition_pushdown_from_having This bug could manifest itself for queries with GROUP BY and HAVING clauses when the HAVING clause was a conjunctive condition that depended exclusively on grouping fields and at least one conjunct contained an equality of the form fld=sq where fld is a grouping field and sq is a constant subquery. In this case the optimizer tries to perform a pushdown of the HAVING condition into WHERE. To construct the pushable condition the optimizer first transforms all multiple equalities in HAVING into simple equalities. This has to be done for a proper processing of the pushed conditions in WHERE. The multiple equalities at all AND/OR levels must be converted to simple equalities because any multiple equality may refer to a multiple equality at the upper level. Before this patch the conversion was performed like this: multiple_equality(x,f1,...,fn) => x=f1 and ... and x=fn. When an equality item for x=fi was constructed both the items for x and fi were cloned. If x happened to be a constant subquery that could not be cloned the conversion failed. If the conversions of multiple equalities previously performed had succeeded then the whole condition became in an inconsistent state that could cause different failures. The solution provided by the patch is: 1. to use a different conversion rule if x is a constant multiple_equality(x,f1,...,fn) => f1=x and f2=f1 and ... and fn=f1 2. not to clone x if it's a constant. Such conversions cannot fail and besides the result of the conversion preserves the equivalence of f1,...,fn that can be used for other optimizations. This patch also made sure that expensive predicates are not pushed from HAVING to WHERE.
* | | | Merge 10.3 into 10.4Marko Mäkelä2019-12-131-0/+1
|\ \ \ \ | |/ / / | | | | | | | | | | | | We disable the MDEV-21189 test galera.galera_partition because it times out.
| * | | MDEV-20900: IN predicate to IN subquery conversion causes performance regressionVarun Gupta2019-12-101-0/+1
| | | | | | | | | | | | | | | | | | | | Disable the IN predicate to IN subquery conversion when the types on the left and right hand side of the IN predicate are not of comparable type.
| * | | Merge remote-tracking branch 10.2 into 10.3Jan Lindström2019-12-021-1/+1
| |\ \ \ | | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: mysql-test/suite/galera/t/galera_binlog_event_max_size_max-master.opt mysql-test/suite/innodb/r/innodb-mdev-7513.result mysql-test/suite/innodb/t/innodb-mdev-7513.test mysql-test/suite/wsrep/disabled.def storage/innobase/ibuf/ibuf0ibuf.cc
| | * | MDEV-17508 Fix bug for spider when using "not like"willhan2019-11-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fix bug for spider where using "not like" (#890) test case: t1 is a spider engine table; CREATE TABLE `t1` ( `id` int(11) NOT NULL DEFAULT '0', `name` char(64) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=SPIDER query: "select * from t1 where name not like 'x%' " would dispatch "select xxx name name like 'x%' " to remote mysqld, is wrong
* | | | Merge branch '10.3' into 10.4Sergei Golubchik2019-09-061-0/+2
|\ \ \ \ | |/ / /
| * | | Merge 10.2 (up to commit ef00ac4c86daf3294c46a45358da636763fb0049) into 10.3Alexander Barkov2019-09-041-0/+2
| |\ \ \ | | |/ /
| | * | MDEV-18156 Assertion `0' failed or `btr_validate_index(index, 0, false)' in ↵Alexander Barkov2019-09-031-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | row_upd_sec_index_entry or error code 126: Index is corrupted upon DELETE with PAD_CHAR_TO_FULL_LENGTH This change takes into account a column's GENERATED ALWAYS AS expression dependcy on sql_mode's PAD_CHAR_TO_FULL_LENGTH and NO_UNSIGNED_SUBTRACTION flags. Indexed virtual columns as well as persistent generated columns are now not allowed to have such dependencies to avoid inconsistent data or index files on sql_mode changes. So an error is now returned in cases like this: CREATE OR REPLACE TABLE t1 ( a CHAR(5), v VARCHAR(5) AS (a) PERSISTENT -- CHAR->VARCHAR or CHAR->TEXT = ERROR ); Functions RPAD() and RTRIM() can now remove dependency on PAD_CHAR_TO_FULL_LENGTH. So this can be used instead: CREATE OR REPLACE TABLE t1 ( a CHAR(5), v VARCHAR(5) AS (RTRIM(a)) PERSISTENT ); Note, unlike CHAR->VARCHAR and CHAR->TEXT this still works, not RPAD(a) is needed: CREATE OR REPLACE TABLE t1 ( a CHAR(5), v CHAR(5) AS (a) PERSISTENT -- CHAR->CHAR is OK ); More sql_mode flags may affect values of generated columns. They will be addressed separately. See comments in sql_mode.h for implementation details.
* | | | MDEV-19961 MIN(timestamp_column) returns a wrong result in a GROUP BY queryAlexander Barkov2019-08-191-0/+3
| | | |
* | | | Merge commit '43882e764d6867c6855b1ff057758a3f08b25c55' into 10.4Alexander Barkov2019-08-131-2/+2
|\ \ \ \ | |/ / /
| * | | MDEV-20273 Add class Item_sum_min_maxAlexander Barkov2019-08-071-2/+2
| | | |
* | | | Merge 10.3 into 10.4Marko Mäkelä2019-07-021-0/+2
|\ \ \ \ | |/ / /
| * | | Merge 10.2 into 10.3Marko Mäkelä2019-07-021-0/+2
| |\ \ \ | | |/ /
| | * | Merge 10.1 into 10.2Eugene Kosov2019-06-231-0/+4
| | |\ \ | | | |/
| | | * Merge 5.5 into 10.1Eugene Kosov2019-06-201-0/+4
| | | |\
| | | | * MDEV-19790 Wrong result for query with outer join and IS NOT TRUE predicateIgor Babaev2019-06-171-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | in where clause The classes Item_func_isnottrue and Item_func_isnotfalse inherited the implementation of the eval_not_null_tables method from the Item_func class. As a result the not_null_tables_cache was set incorrectly for the objects of these classes. It led to improper conversion of outer joins to inner joins when the where clause of the processed query contained IS NOT TRUE or IS NOT FALSE predicates. The coverted query in many cases produced a wrong result set.
* | | | | Merge branch '10.3' into 10.4Oleksandr Byelkin2019-05-191-1/+1
|\ \ \ \ \ | |/ / / /
| * | | | Merge 10.2 into 10.3Marko Mäkelä2019-05-141-1/+1
| |\ \ \ \ | | |/ / /
| | * | | Merge 10.1 into 10.2Marko Mäkelä2019-05-131-1/+1
| | |\ \ \ | | | |/ /
| | | * | Merge branch '5.5' into 10.1Vicențiu Ciorbaru2019-05-111-1/+1
| | | |\ \ | | | | |/
| | | | * Update FSF AddressVicențiu Ciorbaru2019-05-111-1/+1
| | | | | | | | | | | | | | | | | | | | * Update wrong zip-code
* | | | | fix bug for spider where using "not like" (#890)willhan2019-04-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | test case: t1 is a spider engine table; CREATE TABLE `t1` ( `id` int(11) NOT NULL DEFAULT '0', `name` char(64) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=SPIDER query: "select * from t1 where name not like 'x%' " would dispatch "select xxx name name like 'x%' " to remote mysqld, is wrong
* | | | | MDEV-18769 Assertion `fixed == 1' failed in Item_cond_or::val_intGalina Shalygina2019-04-041-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This bug is caused by pushdown from HAVING into WHERE. It appears because condition that is pushed wasn't fixed. It is also discovered that condition pushdown from HAVING into WHERE is done wrong. There is no need to build clones for some conditions that can be pushed. They can be simply moved from HAVING into WHERE without cloning. build_pushable_cond_for_having_pushdown(), remove_pushed_top_conjuncts_for_having() methods are changed. It is found that there is no transformation made for fields of pushed condition. field_transformer_for_having_pushdown transformer is added. New tests are added. Some comments are changed.
* | | | | Merge 10.3 into 10.4Marko Mäkelä2019-03-221-1/+1
|\ \ \ \ \ | |/ / / /
| * | | | MDEV-19008 Slow EXPLAIN SELECT ... WHERE col IN (const1,const2,(subquery))Alexander Barkov2019-03-221-1/+1
| | | | |
* | | | | Merge 10.3 into 10.4Marko Mäkelä2019-03-081-0/+1
|\ \ \ \ \ | |/ / / /
| * | | | Merge 10.2 into 10.3Marko Mäkelä2019-03-081-0/+1
| |\ \ \ \ | | |/ / /
| | * | | MDEV-18383: Missing rows with pushdown condition defined with IF-functionGalina Shalygina2019-03-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | using Item_cond This bug is similar to the bug MDEV-16765. It appears because of the wrong pushdown into HAVING clause while this pushdown shouldn't be made at all. This happens because function that checks if Item_cond can be pushed always returns that it can be pushed. To fix it new method Item_cond::excl_dep_on_table() was added.
| | * | | Merge branch '10.1' into 10.2Oleksandr Byelkin2018-11-151-0/+5
| | |\ \ \ | | | |/ /
| | | * | Merge branch '10.0' into 10.1Oleksandr Byelkin2018-11-151-0/+5
| | | |\ \
| | | | * \ Merge branch '5.5' into 10.0Oleksandr Byelkin2018-11-151-0/+5
| | | | |\ \ | | | | | |/
| | | | | * Backport for "MDEV-17698 MEMORY engine performance regression"Alexander Barkov2018-11-151-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Also, backporting a part of: MDEV-11485 Split Item_func_between::val_int() into virtual methods in Type_handler for easier merge to 10.3.
| | | * | | Merge branch '10.0' into 10.1Oleksandr Byelkin2018-08-211-0/+1
| | | |\ \ \ | | | | |/ /
| | | | * | Merge branch '5.5' into 10.0Oleksandr Byelkin2018-08-151-0/+1
| | | | |\ \ | | | | | |/
| | | | | * MDEV-15475: Assertion `!table || (!table->read_set || ↵Oleksandr Byelkin2018-08-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | bitmap_is_set(table->read_set, field_index))' failed on EXPLAIN EXTENDED with constant table and view Print constant ISNULL value independent. Fix of printing of view FRM and CREATE VIEW output
* | | | | | MDEV-7486: Condition pushdown from HAVING into WHEREIgor Babaev2019-02-191-18/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Optimized the code that removed multiple equalities pushed from HAVING into WHERE. Now this removal is postponed until all multiple equalities are eliminated in substitute_for_best_equal_field().
* | | | | | MDEV-18636 The test case for bug mdev-16765 crashes the serverGalina Shalygina2019-02-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | in the tree bb-10.4-mdev7486 The crash was caused because of the similar problem as in mdev-16765: Item_cond::excl_dep_on_group_fields_for_having_pushdown() was missing.
* | | | | | MDEV-7486: Condition pushdown from HAVING into WHEREGalina Shalygina2019-02-171-2/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Condition can be pushed from the HAVING clause into the WHERE clause if it depends only on the fields that are used in the GROUP BY list or depends on the fields that are equal to grouping fields. Aggregate functions can't be pushed down. How the pushdown is performed on the example: SELECT t1.a,MAX(t1.b) FROM t1 GROUP BY t1.a HAVING (t1.a>2) AND (MAX(c)>12); => SELECT t1.a,MAX(t1.b) FROM t1 WHERE (t1.a>2) GROUP BY t1.a HAVING (MAX(c)>12); The implementation scheme: 1. Extract the most restrictive condition cond from the HAVING clause of the select that depends only on the fields that are used in the GROUP BY list of the select (directly or indirectly through equalities) 2. Save cond as a condition that can be pushed into the WHERE clause of the select 3. Remove cond from the HAVING clause if it is possible The optimization is implemented in the function st_select_lex::pushdown_from_having_into_where(). New test file having_cond_pushdown.test is created.
View Lorry Controller Status